GNOME Bugzilla – Bug 789033
GtkFileChooserNative's action GTK_FILE_CHOOSER_SAVE crash using native compiler outside from MSYS2.
Last modified: 2017-10-20 11:34:28 UTC
Hi to everybody, I go into my problem: Try it out Like this: [CODE] #include <gtk/gtk.h> static void create_win32_native_file_chooser(GtkWidget *widget, gpointer user_data) ; static void create_win32_native_file_chooser(GtkWidget *widget, gpointer user_data) { GtkWidget *window = gtk_widget_get_toplevel(widget) ; GtkFileChooserNative *win32_native_file_chooser = gtk_file_chooser_native_new("title", GTK_WINDOW(window), GTK_FILE_CHOOSER_ACTION_SAVE, "accept label", "cancel label") ; gtk_native_dialog_run(GTK_NATIVE_DIALOG(win32_native_file_chooser)) ; gtk_native_dialog_destroy(GTK_NATIVE_DIALOG(win32_native_file_chooser )) ; return ; } int main (int argc, char *argv[]) { gtk_init(&argc, &argv) ; GtkWidget *window, *button ; window = gtk_window_new(GTK_WINDOW_TOPLEVEL) ; button= gtk_button_new_with_label("test") ; g_signal_connect(button, "clicked", G_CALLBACK(create_win32_native_file_chooser) , NULL); gtk_container_add(GTK_CONTAINER(window), button) ; gtk_main() ; return 0 ; } [/CODE] Compile it with MSYS2: x86_64-w64-mingw-gcc. --- Then make a directory outside the MSYS2 environment (the $PATH must be clean without MSYS2). And execute this script given binary and directory: [CODE] #! /bin/bash ########################################### # # # A script for mingw distributing copying # # every needed *.dll to destination given # # as argument ($2), # # from binary given as argument ($1) # # # ########################################### function usage { echo "a script to copy all required dll files from a binary to a destdir." echo "usage: $0 pathtobin destdir" exit 1 } if [[ ! -f $1 ]] || [[ ! -d $2 ]] ; then usage ; else ldd $1 | grep /mingw64/bin/ | cp $(gawk '{print $3}' ) $2 ldd $1 | grep /mingw64/bin/ | echo "$(gawk '{print $3}' )" # A try for cygwin: # #objdump -p $1 | grep "DLL Name" | cp $(printf "%s%s" "/usr/x86_64-w64-mingw32/sys-root/mingw/bin/" $(gawk '{print $3}')) $2 #objdump -p $1 | grep "DLL Name" | echo $(printf "%s%s" "/usr/x86_64-w64-mingw32/sys-root/mingw/bin/" $(gawk '{print $3}')) echo "copy to $2" cp $1 $2 echo "copy $1 to $2" exit 0 ; fi [/CODE] Then execute the binary at the location outside the MSYS2 environment. It crash on my system. If we find what bug I can package my program using inno-setup what would be great and not hope.
If I would use the action GTK_FILE_CHOOSER_OPEN it would work. And for folders opening or saving it desn't work.
Created attachment 361647 [details] A slightly cleaner version of the testcase, with W32 gdb attachment code I think that since you have a development environment, first thing to do is to run your program under gdb to get a better understanding of where exactly it's crashing. I'm attaching a cleaned up version of your testcase (your coding style is atrocious, by the way). Compile, copy and run it the same way you did with your original version. It will show a message box with the process ID. After that you should run gdb[1] (note that if you are running the program as administrator, for some reason, gdb must be run as administrator as well), then give it the following commands: attach process_id b gtk_init c where "process_id" is the process id of your program. After that press the OK button, and gdb will stop the program when it enters the gtk_init() function. Now issue the "fin" command to run until the end of that function, and then use "s" and/or "n" to step through you program, or "c" to just let it run by itself. Either way, it should catch the moment your program crashes. Once it does, issue the "bt" command and post its output here, along with any output your program shows in its console window. If your program crashes *before* it has a chance to show a message box, then the problem is most likely appears during DLL initialization phase. That is more difficult to debug, and you might want to also copy gdb (and any DLLs it needs) into your program directory, and run it under gdb directly (again, see [1]) to be able to catch those. If that doesn't work (the program crashes before gdb is able to latch onto it), then the problem is definitely in DLLs, or some other initialization code, and i'll have to try to reproduce this and debug it myself. I can also hypothesize about some problems you might be having - GTK+ and glib use a number of resources (such as gsettings schemas) that are not packed into DLLs, so your script for copying dependencies will not cover these. Absence of these files can and will result in some glib- or gtk-using program crashing during initialization phase. If you want to bundle all the files that an application might need, a better strategy would be to find the *packages* that each dependency DLL belongs to and copy the contents of those packages, as well as any packages they depend on. I don't have a script for doing that (though i can imagine that MSYS2 developers either have it, or are very interested in developing it, so you better go ask them). [1] You can do this much easier by running gdb *and* your program in one go, usually by invoking "gdb --args path-to-your-program.exe", but that does not guarantee that the program will run *outside* of the environment (in your case - MSYS2) from which gdb is being invoked. Seeing that you want your program to run separately, i thought that this trick with a messagebox will work just fine.
Hello, I have run gdb on my real program before posting this BUG-REPORT. Like this: [CODE] $ gdb ./my_prg.exe [...] (gdb) r Crash dump .... (gdb) bt # It points clearly on the instantiation of the GtkFileChooserNative with GTK_FILE_CHOOSER_SAVE as action. [/CODE] Because gdb output the line where it crash. I re-tell you that the FILE_CHOOSER_ACTION_OPEN is the only which works using my *.dll copy script. But Into the MSYS2 development environment it works well. --- If doubt about that I omit some dependencies because I successfully make a build using the same script for the Windows version of my music player: Micro Music Player <http://www.open-source-projects.net/mmp/mmp> --- [QUOTE] If you want to bundle all the files that an application might need, a better strategy would be to find the *packages* that each dependency DLL belongs to and copy the contents of those packages, as well as any packages they depend on. I don't have a script for doing that (though I can imagine that MSYS2 developers either have it, or are very interested in developing it, so you better go ask them). [/QUOTE] So why writing program if it's not for packaging your program as Windows version using inno-setup since it works well. Except for yourself. --- By the way before writing my *.dll copy script I ask if I must copy some system's *.dll into my package and the answers is clearly NO. :note: The program crash report from Windows points on KERNELBASE.dll --- [QUOTE] I can also hypothesize about some problems you might be having - GTK+ and glib use a number of resources (such as gsettings schemas) that are not packed into DLLs, so your script for copying dependencies will not cover these. [/QUOTE] By the way: Can you write a script for copying this dependencies ? Or at least tell me a bit more about what you mean. --- Best regards, mrcyberfighter.
(In reply to Brüggemann from comment #3) > > Crash dump .... > > (gdb) bt > > # It points clearly on the instantiation of the GtkFileChooserNative with > GTK_FILE_CHOOSER_SAVE as action. > > [/CODE] > > Because gdb output the line where it crash. > > I re-tell you that the FILE_CHOOSER_ACTION_OPEN is the only which works > using my *.dll > > copy script. But Into the MSYS2 development environment it works well. Post the contents of the backtrace here.
Your reluctance to provide a backtrace hampered my enthusiasm for looking into this bug. Nevertheless, by peering into my crystal ball i was able to deduce some causes of your problem (which i already mentioned above), and your insistence that only ACTION_SAVE causes a crash, while ACTION_OPEN does not, coupled with my tests with different actions, did provide a strong indication that my guess was, indeed, correct. I can't be sure until you confirm this (or provide a backtrace, which will make the cause of this particular bug clear as day), but i'm pretty sure that the crash you are experiencing is due to the absence of GSettings schemas. I'm somewhat surprised that you haven't noticed this, since in your case the missing schemas are also accompanied by missing icons. Absence of icons is *extremely* visible, and you get verbose warnings posted into your program's standard output (or maybe standard error, i'm not sure) stream. When it crashes it *also* posts a critical error about missing schemas, so i have no idea how you were able to miss this. Anyway, icons live in /share/icons, schemas live in /share/glib-2.0/schemas. Thus, if your program and its dependencies are in c:/foo/bar/bin/, then icons should be in c:/foo/bar/share/icons/ and schemas should be c:/foo/bar/share/glib-2.0/schemas/. If your program and its dependencies are in c:/foo/bar/ (i.e. no /bin subdirectory), then... i'm not sure. It's probably documented somewhere. Note also that GTK+ reads icon metadata from an icon cache file and schemas from a compiled schemas file. Icon cache is updated by gtk-update-icon-cache (or by gtk-update-icon-cache-3.0, if your package manager has separate gtk2 and gtk3 versions), and schemas are compiled by glib-compile-schemas. Your package manager (MSYS2 pacman) handles cache and schema updates automatically when packages are installed (icons cache has to be regenerated every time new icons are installed or old ones are updated; schemas have to be recompiled every time a package adds a new schema or changes the existing one). I don't know for sure, but it *seems* that compiled schemas and icon cache do not include any absolute path information, so you *might* get away with just copying existing cache files and compiled schemas along with the icons (not sure whether you need uncompiled schema xmls), and it'll just work.
Hello to all the Gtk team, Your suspicions was right, Because after your clear answers I've chosen to include the gschemas as say in the documentation: [QUOTE] At runtime, GSettings looks for schemas in the glib-2.0/schemas subdirectories of all directories specified in the XDG_DATA_DIRS environment variable. [QUOTE] So I copy them like an idiot the gschemas in a sub-folder like this: [CODE] $ pwd /c/Users/edward/Desktop/tmp $ ls gfast-copy.exe libgdk_pixbuf-2.0-0.dll libpangocairo-1.0-0.dll glib-2.0 libgdk-3-0.dll libpangoft2-1.0-0.dll libatk-1.0-0.dll libgio-2.0-0.dll libpangowin32-1.0-0.dll libbz2-1.dll libglib-2.0-0.dll libpcre-1.dll libcairo-2.dll libgmodule-2.0-0.dll libpixman-1-0.dll libcairo-gobject-2.dll libgobject-2.0-0.dll libpng16-16.dll libepoxy-0.dll libgraphite2.dll libstdc++-6.dll libexpat-1.dll libgtk-3-0.dll libwinpthread-1.dll libffi-6.dll libharfbuzz-0.dll share libfontconfig-1.dll libiconv-2.dll zlib1.dll libfreetype-6.dll libintl-8.dll libgcc_s_seh-1.dll libpango-1.0-0.dll $ cd glib-2.0/schemas $ ls gschema.dtd org.gtk.Settings.ColorChooser.gschema.xml gschemas.compiled org.gtk.Settings.Debug.gschema.xml org.gtk.Demo.gschema.xml org.gtk.Settings.EmojiChooser.gschema.xml org.gtk.exampleapp.gschema.xml org.gtk.Settings.FileChooser.gschema.xml $ cd .. $ cd .. $ glib-compile-schemas ./glib-2.0/schemas [/CODE] But the idiot I be don't have understand that the XDG_DATA_DIRS is not my packaging directory: ``/c/Users/edward/Desktop/tmp`` But the idiot understand what you have written to me on gnome-BUGZILLA: [QUOTE] ... Anyway, icons live in /share/icons, schemas live in /share/glib-2.0/schemas. Thus, if your program and its dependencies are in c:/foo/bar/bin/, then icons should be in c:/foo/bar/share/icons/ and schemas should be c:/foo/bar/share/glib-2.0/schemas/. ... [/QUOTE] I've made this mistake because I get sub-folder under: ``/c/Users/edward/Desktop/tmp/share`` And don't want to pollute it even if it doesn't matter. Finally I set the gschemas under: `` ./share/glib-2.0/schemas/`` And *IT WORKS* now, thanks to a proud *GThacKtivists* which save my Windows version. The only error you have made is the given folder-path /mingw64/share/glib-2.0/schemas i.e $(prefix)/share/glib-2.0/schemas instead of /share/glib-2.0/schemas but this does not matter a hacker. :question: If I don't need the Adwaita icons into my programs must I include them into the package ? And what about the hicolor icons ? Because it seems that the hicolor icons are used for the cross for closing the Window and for minimize/maximize the Window icons. --- .1 == At first please excuse me, for all the injuries I have said to the GTK-Team on the mailing list (gtk-app-devel-list@gnome.org). I'm not bad but when things get wrong I become nervous and want to kill the entire world. So I have posted injuries for what I'm not proud about on the gtk-app-devel mailing list. I sends you my true excuses and I will never more do this again. To let my emotions make me sin so hard. | Thanks to understand that you become bad minded and nervous when your program bug and you think: 1. You have done all right (because it worked with Micro Music Player). 2. The BUG comes from the underlying library (What's wrong). 3. The last time you did the same with my useful *.dll copying script and it works well (But this time it's not sufficient). .2 == **BIG** *thanks* for the help from the gnome-BUGZILLA team. You make a Windows version possible (an auto-extractable *.exe) what was no more hope. Thanks to make the work possible for all the users at first me. The package I gonna release is named gfast-copy. It contains 2 binaries: + A graphical version. + A command line version. For a simple chunk file copier. I have some work to do before releasing and the gnome-bugzilla team, is gracefully thanks into the concern files and surely on the future web-page. You will find the programs next at: <http://www.open-source-projects.net/gfast-copy/gfast-copy>. .3 == The next time I will add a traceback and the Windows crash report too. And provide my gtk version. :question: Do you mean the gdb output because no coredump is generated. Ubuntu (my development O.S because of rolling release) doesn't generate crash reports for thirty part programmers as it do for a long time ago. Unlucky but OpenGL support is great under Ubuntu. .4 == Excuse me again if I have hurt you voluntary but you're not the only workers and we are all sinners anyway. 5. == I will remove from all concern files the notice about the GtkFileChooserNative bug: + autotools build (GNU/Linux, MacOSX, MSYS2, Cygwin supported). + *.deb + *.exe (to do next). + *.rpm (not yet done). + source files. :by the way: The MacOSX version the GtkFileChooserNative display an abnormal GNU system file chooser is this normal or not ? --- P.S: I can't imaging that gschemas (what I don't known about) are so important. To the point that it make crash an application. A short explanation of it is welcome. --- :note: Extract from the python zen to which I agree: ... + Simple is better than complicate. + Complicate is better than complex. + Explicit is better than implicit. ... I started to program with python but no more. Finally thanks for the clear answers: it works grace of you (the gnome-bugzilla community), thanks. mrcyberfighter.
(In reply to Brüggemann from comment #6) > :question: If I don't need the Adwaita icons into my programs must I include > them into the package ? > And what about the hicolor icons ? > Because it seems that the hicolor icons are used for the cross > for closing the Window and for minimize/maximize the Window icons. The documentation says that GTK looks for icons and cursors in the current icon theme, which is usually Adwaita. If it fails to find an icon in currently-used theme, it looks in the fallback "hicolor" theme. Thus "hicolor" is the agreed-upon theme for applications to put their custom icons into. You might get away with not including *all* icons in your distribution, but i don't know a way to determine in advance which icons you will need and which you will not. Clearly, as you've discovered already, you will need at least the minimize-maximize-close icons for the window decorations. You can certainly save some space by not including some of the cursors (if you have them), but again, i have no readily-available way to tell you which ones are safe to leave out (though this case is easier - there's a cursor map built into W32 backend, which will, by default, be used to merge Windows cursor with the cursors from the current theme, thus allowing GDK to show normal Windows cursors, for actions that are covered by them (pointer, wait, resize, text, drag, hand), and to show theme cursors for the other actions, for which there are no Windows cursors; you might be able to find that map in the source code and use it to determine which cursors to not include). However, since you need *some* icons, i see no reason to not to include all of them, unless you desperately want to save some space. I mean, you already get to have the share/icons subdirectory and an icon cache. As for the schemas, you'll have to ask glib developers for the rationale behind these things, that was before my time. > :question: Do you mean the gdb output because no coredump is generated. I meant the output of the "bt" command. Indeed, the use of gdb coredumps on Windows is an interesting but ultimately arcane topic. > :by the way: The MacOSX version the GtkFileChooserNative display an > abnormal GNU system file chooser is this normal or not ? No idea, i don't use MacOSX, nor do i touch any code for that backend (it's not even a certainty that you're using the quartz backend; it's possible that you're using the usual X11 backend...).