GNOME Bugzilla – Bug 702788
PyGObject 3.x on x64 Windows crashing as a 64-bit binary
Last modified: 2017-03-23 15:28:55 UTC
Hi, As I was trying out the build of PyGObject on my Windows 7 x64 system, it seems that it fared much better as a 32-bit build rather than a 64-bit build. My few observations on this regard on running the GTK3 pygi demo scripts: -32-bit builds ran quite well, but 64-bit builds crashed with Python 2.7 and Python 3.3 upon startup, but ran on Python 3.2 (but crashes at some points) -The .gir files that I generated for the GTK+ stack seemed identical between 32-bit and 64-bit builds -I might need to test further on other PyGI scripts, such as those for Clutter, etc I am suspecting that this might be caused by alignment issues in the code (for instance, maybe some places assumed sizeof (void *) == 4, but sizeof (void *) is 8 on Windows), but I still need to investigate further regarding this part, so I am opening this bug in case anyone is interested in this issue. With blessings, thank you!
Hi, the line "but sizeof (void *) is 8 on Windows" should read "but sizeof (void *) is 8 on x64 Windows builds)". Sorry for any confusion caused. With blessings.
What was the build environment for this, MSVC or MinGW?
Hello John, Visual Studio 2008 for Python 2.7.3 and 3.2.3 (and Visual Studio 2010 for Python 3.3) in both x86 and x64 flavours, using the same compiler (and same version) for all of the GTK+ stack and dependencies (including G-I) for each respective config. I am not an avid MinGW-using guy :) Were you able to run PyGObject 3.x compiled for x64 on Windows (I guess that you are using MinGW), and if so, can I know how it fared for you? With blessings, thank you!
Hi, Sorry for not looking back into this bug for a while. It seems that although it is now possible to launch the GTK+ Python/GI demo, the x64 builds of PyGObject still crashes when running the "Dialog and Message Boxes" demo, right when hitting the "Interactive Dialog" button. It seems that the script crashes right when self.entry1.get_text() is called around line 115 (which is local_entry1.set_text(self.entry1.get_text())). Again, interestingly this does not affect x86 builds of PyGObject, so my suspicion would be somewhere we have incorrect sizes of variables that are used on x64 builds (or scripts) somewhere, as we have the following differences between Win32/x86 and x64 for the following, as far as I can tell: size_t, void* and time_t are all 8-bytes on x64 whereas they are 4-bytes on Win32/x86. I have yet to pin down where exactly this is happening, so this is what I know so far about this. p.s. John, were you able to build PyGObject as an x64 binary on Windows with MinGW-64? Did you hit this issue as well, if so? With blessings, thank you!
Hi, Upon further investigations, interestingly this is what I see on Windows x64 builds (32-bit Windows builds run normally, as mentioned earlier): If I have text in both of the input boxes in the "Dialog and Message Boxes" and click the "Interactive Dialog" button, the dialog box will appear normally, with the corresponding texts. In the dialog that pops up, if I have texts in one or both of the input boxes and click OK, it runs normally and copies the text(s) normally. If I set both input boxes to have no text and click OK, then it crashes. This is what I see so far. With blessings, thank you!
(In reply to comment #5) > In the dialog that pops up, if I have texts in one or both of the input boxes > and click OK, it runs normally and copies the text(s) normally. If I set both > input boxes to have no text and click OK, then it crashes. That is a useful clue. I'll look around to see if there is anything odd in these code paths. Does the gtk3-demo C demo of the same name from GTK+ work? Another thing that would help here is creating a simplified demo which just calls Gtk.Entry.get_text() and see if it also crashes on empty text. I do have Windows 7 & 8 x64 installs (I just don't use them for development). If it comes down to it, I can eventually try to build on windows (not sure I can get that done before the hard code freeze tomorrow). Any pointers for the easiest route to accomplish windows builds would be helpful (or if anyone watching this ticket can help debug the problem on windows it would be much appreciated).
Hi Simon, Thanks for the notes. I would try to check a simple case of Gtk.Entry.get_text() ASAP, but just to let you know, the C demo of the same name from GTK+-3.x does work well as Win32/x86 as well as x64 binaries. I might not be able to provide help for you for building the stack on Windows, as I use Visual C++ (instead of MinGW) to build the stack (perhaps OpenSUSE's build service and/or Tarnyko's build might be good starters, as this problem does hit 3.10.x as well). With blessings, thank you!
Created attachment 282234 [details] Test scripts that crashes Hi, Sorry I was not able to revisit this issue for a long time... apparently what seems to have happened after I imported the faulthandler module is that the Gtk.Entry() is NULL when the script does self.entry1 = Gtk.Entry() on x64, so doing self.entry1.get_text() immediately would crash on x64 (please see the attached test script, that is a stripped down version of the dialogs.py demo). However, the test script would run fine on Win32 (32-bit) builds, AFAICT. p.s. My .gir files for the GTK stack are identical for Win32 and x64 builds, except for the GLib-2.0.gir file. Should I attach those? With blessings, thank you!
Created attachment 283072 [details] The callstack at the time of the crash (Access Violation) Hi, This is the callstack I had when running the latest GIT snapshot (2014 08/11 Taipei Standard Time) against Python 3.3.5/x64. With blessings, thank you!
Hi, There is a build of gedit for Windows/x64 from Ignacio (of gedit) from http://blogs.gnome.org/nacho/2014/07/30/gedit-3-for-windows/, which also seems to be hit by this problem. Another demo that demonstrates this problem is the clipboard demo, so if one does not enter any text and hits the "copy" button, PyGObject crashes, and it seems from the script that it is doing the more or less the same thing as in the test script (in comment #8), and in the dialogs demo. With blessings, thank you!
I can't reproduce this with current msys2 builds (mingw64, python3.5.3, pygobject 3.22). I tried the attached script and the clipboard demo. Is this still a problem?