| |
Slajerek
Registered: May 2015
Posts: 62 |
Release id #187948 : C64 65XE Debugger V0.64.58
I am using NFD library to open files in Linux. Please guide me how to fix this annoying bug.
https://sourceforge.net/p/c64-debugger/code/ci/master/tree/MTEn.. |
|
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Gave this a shot, since I tend to do quite a bit of Gtk stuff.
Note: I haven't used C++ properly for about 15 years, and I'm not familiar with the codebase, so some of my assumptions might be off.
First off: the NFD stuff shouldn't use gtk_init_check(), since you call gtk_init() in Linux/SYS_Startup.cpp. gtk_init_check() doesn't check if gtk_init() was called, it allows you to continue after that call, for example switching to a text interface, gtk_init() will just barf when it cannot initialize Gtk.
Unfortunately that doesn't seem to be the bug.
The 'bug' happens in Gtk3 while calling gtk_file_chooser_new():
Thread 1 "c64debugger" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff68d87bb in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff68c3535 in __GI_abort () at abort.c:79
#2 0x00007ffff72cadc3 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff7324e1e in g_assertion_message_error ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff7ab68e5 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#5 0x00007ffff7ab6fe5 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#6 0x00007ffff7ab70a4 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#7 0x00007ffff7ab7288 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#8 0x00007ffff7aca70d in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#9 0x00007ffff7a288d3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x00007ffff7a2ca51 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#11 0x00007ffff7acaed3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x00007ffff7b87c81 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x00007ffff7b884b0 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x00007ffff7b8859e in gtk_widget_get_preferred_width ()
at /lib/x86_64-linux-gnu/libgtk-3.so.0
#15 0x00007ffff79d78df in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#16 0x00007ffff7a288d3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#17 0x00007ffff7a2ca51 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#18 0x00007ffff79d83c3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#19 0x00007ffff7b87c81 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
--Type <RET> for more, q to quit, c to continue without paging--c
#20 0x00007ffff7b884b0 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#21 0x00007ffff7b8859e in gtk_widget_get_preferred_width () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#22 0x00007ffff7b87c81 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#23 0x00007ffff7b884b0 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#24 0x00007ffff7b8859e in gtk_widget_get_preferred_width () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#25 0x00007ffff79d2841 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#26 0x00007ffff7b64396 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#27 0x00007ffff7b87c81 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#28 0x00007ffff7b884b0 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#29 0x00007ffff7b8859e in gtk_widget_get_preferred_width () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#30 0x00007ffff7a288d3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#31 0x00007ffff7a2ca51 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#32 0x00007ffff7ae44c7 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#33 0x00007ffff7b87c81 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#34 0x00007ffff7b884b0 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#35 0x00007ffff7b8859e in gtk_widget_get_preferred_width () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#36 0x00007ffff7ae41dd in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#37 0x00007ffff7a288d3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#38 0x00007ffff7a2ca51 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#39 0x00007ffff7ae4350 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#40 0x00007ffff7a288d3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#41 0x00007ffff7a2ca51 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#42 0x00007ffff7ae446a in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#43 0x00007ffff7b87d4b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#44 0x00007ffff7b884b0 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#45 0x00007ffff7b879b1 in gtk_widget_get_preferred_height () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#46 0x00007ffff7c29adf in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#47 0x00007ffff7c2a075 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#48 0x00007ffff73e6ecb in g_object_set_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#49 0x00007ffff73e779c in g_object_set () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#50 0x00007ffff7b725e0 in gtk_scrolled_window_set_hadjustment () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#51 0x00007ffff73e48f9 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#52 0x00007ffff73e5fad in g_object_newv () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#53 0x00007ffff79df0c2 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#54 0x00007ffff79e1b93 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#55 0x00007ffff7300553 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#56 0x00007ffff730163d in g_markup_parse_context_parse () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#57 0x00007ffff79e2576 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#58 0x00007ffff79dd3e4 in gtk_builder_extend_with_template () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#59 0x00007ffff7c3ed07 in gtk_widget_init_template () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#60 0x00007ffff7a85c9b in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#61 0x00007ffff7402107 in g_type_create_instance () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#62 0x00007ffff73e4548 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#63 0x00007ffff73e5fad in g_object_newv () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#64 0x00007ffff79df0c2 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#65 0x00007ffff79e06b5 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#66 0x00007ffff79e215d in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#67 0x00007ffff73006b2 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#68 0x00007ffff73017f6 in g_markup_parse_context_parse () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#69 0x00007ffff79e2576 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#70 0x00007ffff79dd3e4 in gtk_builder_extend_with_template () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#71 0x00007ffff7c3ed07 in gtk_widget_init_template () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#72 0x00007ffff7a7d3ce in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#73 0x00007ffff7402107 in g_type_create_instance () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#74 0x00007ffff73e4548 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#75 0x00007ffff73e63d4 in g_object_new_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#76 0x00007ffff73e6709 in g_object_new () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#77 0x00007ffff7a7dea4 in gtk_file_chooser_dialog_new () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#78 0x0000555555af5fef in NFD_OpenDialog ()
#79 0x00005555557cf880 in SYS_DialogOpenFile(CSystemFileDialogCallback*, std::__cxx11::list<CSlrString*, std::allocator<CSlrString*> >*, CSlrString*, CSlrString*) ()
#80 0x000055555570cd26 in CViewC64::ShowDialogOpenFile(CSystemFileDialogCallback*, std::__cxx11::list<CSlrString*, std::allocator<CSlrString*> >*, CSlrString*, CSlrString*) ()
#81 0x00005555556c91fa in CViewMainMenu::OpenDialogInsertD64() ()
#82 0x0000555555707f4f in CViewC64::ProcessGlobalKeyboardShortcut(unsigned int, bool, bool, bool) ()
#83 0x000055555570a9a5 in CViewC64::KeyDown(unsigned int, bool, bool, bool) ()
#84 0x000055555567e6c6 in CGuiMain::KeyDown(unsigned int, bool, bool, bool) ()
#85 0x0000555555b843e1 in main ()
(gdb)
As you can see, Gtk fails to get a proper size for its dialog and aborts.
I suspect this is due to threading, since I wrote a small test case using a single thread (basically a main() that calls gtk_init() and then gtk_file_chooser_dialog_new() and then calling gtk_dialog_run(), just like what NFD does). That works.
I have noticed that Gtk (and Qt) can be a little difficult when using threads, they prefer their own threading models, so it could be any non-main thread cannot access the GMainLoop and thus gtk code cannot get the info it requires.
I tried getting a GdkWindow from the X11 Window, or spawning a temporary GtkWindow as a parent for the NFD code, so I could push the dialog to front, that didn't work, still same abort. (GtkWindow doesn't even show, but my taskbar indicates its there).
So, I suspect supporting Gtk3 dialogs will involve a little more code than that NFD 'lib'. You'd probably want to at least have a proper GMainLoop which gets updated in the main thread whenever there's time left in a frame.
(Something similar is happening with VICE now).
Sorry I can't be of more help, but perhaps this helps a little to track down the bugs. |
| |
Slajerek
Registered: May 2015
Posts: 62 |
Bow Compyx :)
I saw this on my valgrind and gdb. I've thought that I can just make my own GTK thread, I do not want to stick to that GMainLoop to not create overhead of users who already complained about the speed of this tool :) i.e. we need to optimise this. But maybe running a simple GMainLoop would be the real solution here. Will try, thanks for the hint :)
I've seen alternate method of throwing UI file select dialog to the user via bash. Maybe that's a solution too. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Im fine with using the non-Gtk3 dialogs. Though perhaps they could use the cwd as their directory and allow keyboard navigation. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
But they dont look native! How dare you! |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
They might look native on my Gtk3 Cinnamon desktop, didn't get that far yet. Not my problem you use Motif or Xaw or Tk, some of us like to get with the time, apart from the C64. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
But emu with non native file open dialog is unusable! |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
At least the non-native stuff works. Have you tried the flathub or the snap packages? It's bollocks.
They use the GtkFileChooserNative (https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNati..)
That blows. |
| |
Mace
Registered: May 2002
Posts: 1799 |
I reckon credits for Slammer/Turtles are wrong.
Probably should be Slammer/Camelot, right? |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
credit corrected |
| |
Slajerek
Registered: May 2015
Posts: 62 |
Thanks. I filled a bug at NFD here:
https://github.com/mlabbe/nativefiledialog/issues/84
I tried to debug it on my own and understand the issue, the problem is it does not crash at all on my Debian Jessie, which is a bit tricky to debug then :)
Note, that you can always change dialogs to my own implementation anyway in Settings/UI/Use system dialogs, just set to "No" and instead of GTK you'll see my own simple open/save file dialogs.
Btw. I used gtk_file_chooser_dialog_new in my previous GTK dialogs implementation, but apparently it locked whole app badly. That was probably also due to missing GMainLoop. I've seen a possibility to create our own GMainLoop temporarily and was using that trick (i.e. so the event loop was set to that temporary one just for the time when dialog was opened), which worked OK on some older systems, but not now anymore.
I guess I need to change NFD GTK dialogs to also allow Zenity implementation and make these GTK system dialogs not set as default. Anyway, thanks again for your help. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Sorry I couldn't be of more help. Let's see what the NFD dev has to say.
I'm using your (X11) dialogs, that works fine for me. I don't need a fancy UI for a tool to be useful. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Sorry I couldn't be of more help. Let's see what the NFD dev has to say.
I'm using your (X11) dialogs, that works fine for me. I don't need a fancy UI for a tool to be useful.
When will linux/x11/gtk/open source world ever get this right.. *sigh*
I had these exact same issues 20 years ago. :( |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
As if those problems dont exist in native closed source GUIs, they suck just as bad :) |
| |
Slajerek
Registered: May 2015
Posts: 62 |
So this is not ready for release yet, but please check, I replaced GTK with Zenity. This ought to be a maintenance release that fixes all problems, so I can then merge to vice 3.4 :)
064582rc2 - with zenity
https://drive.google.com/drive/folders/1nF0rIAed1dVYRpoIhKa-sxl.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
$ ./c64debugger-064582rc2-linux-x64
./c64debugger-064582rc2-linux-x64: error while loading shared libraries: libxcb-util.so.0: cannot open shared object file: No such file or directory
$ locate libxcb-util.so
/usr/lib64/libxcb-util.so
/usr/lib64/libxcb-util.so.1
/usr/lib64/libxcb-util.so.1.0.0
do you really need to import that specific version? :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote:
$ ./c64debugger-064582rc2-linux-x64
./c64debugger-064582rc2-linux-x64: error while loading shared libraries: libxcb-util.so.0: cannot open shared object file: No such file or directory
$ locate libxcb-util.so
/usr/lib64/libxcb-util.so
/usr/lib64/libxcb-util.so.1
/usr/lib64/libxcb-util.so.1.0.0
do you really need to import that specific version? :)
Just symlink and wait for a segfault! ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
NO! |
| |
Slajerek
Registered: May 2015
Posts: 62 |
I do not link anything specifically, this is the Makefile:
https://sourceforge.net/p/c64-debugger/code/ci/master/tree/MTEn..
Meaning that my old build machine Debian is outdated or what? I actually do not understand why this fails, anyway some so magic from Linux :) meaning that it should be easy to fix, I just need to scrap my faithful Debian into a new brand whatever distribution in which that compiles properly. Looks like old configuration for pkg-config... but why this fails on your machines I do not know. For me it is a pkg-config bug. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
static linking is always a gamble....to make it really work, you really have to statically link ALL libs, not just some =D
what repo/branch do i have to build? that will be easier =) |
| |
Slajerek
Registered: May 2015
Posts: 62 |
This is on Sourceforge here:
https://sourceforge.net/p/c64-debugger/code/ci/master/tree/
It should be just matter of cd MTEngine; make |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I checked out the latest version from trunk, moved ~/.C64Debugger/settings.dat to settings.dat.bak (to avoid using the X11 dialogs), and now Ctrl+8 actually pops up a usable Gtk3 dialog.
Edit:
uname: Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux
/etc/debian_version: 10.4
gtk3: 3.24.5
glib: 2.58.3
|
| |
Compyx
Registered: Jan 2005
Posts: 631 |
While am at it, Gtk4 will deprecated/remove `result = gtk_dialog_run()` because that breaks the nature of a UI, a UI is event driven and thus async. I agree with the Gtk devs at this point.
So in the 'future', NFD (or perhaps your own custom code) will have to set up a temp GMainLoop, create a GtkDialog with an event handler for "response" and in that event handler call back to your code to signal a filename/path was accepted, or not.
The problem with this is that gtk_dialog_run() blocks, but:
GtkWidget *dialog = gtk_dialog_new(...);
gtk_widget_show(dialog);
will not.
So you need to make the dialog 'Modal'. Since you don't have a proper GtkWindow/Widget to use as a parent to set Modal for, you'd have to use some OS-dependent code to somehow grab an X11, Win32 or whatever window handle via GDK
and use that as the parent.
Another thing is unrolling the GMainLoop events and then destroying the temp GMainLoop, via the GtkDialog's "response" event handler. I have a feeling it'll not go well.
By Wodan, I love Gtk (or any other UI toolkit with its own threads and objects, looking at you Qt!) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
Works here too!
One weird thing... UPX crashes when packing the exe... which is weird and unexpected. However, i'd suggest making this a seperate build step, and copy the binary to be packed first - in that case UPX crashing wont really matter and still leave you with a working binary. (actually... just dont use upx, 11mb is nothing, depacking will be slower than just loading the binary) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I did this without upx. UPX is weird and just adds a lot of time to the build process. |
| |
Slajerek
Registered: May 2015
Posts: 62 |
I just kept UPX because it looks nice to see a small self-contained and portable binary, but more and more people are complaining so I guess I'll have to give it a go.
Regarding that experimental dev version, note it uses Zenity, not direct GTK. Thus, the dialog is spawned through a forked process that communicates over stdout, meaning that the original process does not have to have the GMainLoop. I hope that solves that open/file dialogs problem once for all :) Thanks for testing. |
