Description of problem: For some reason, glib2 is compiled with valgrind support. This leads to a special code sequence to check if valgrind is running. Among other things, this code sequence also contains an xchg ebx, ebx instruction. In g_type_free_instance, the address of the memory to be freed is stored in rbx, and the xchg ebx,ebx zeros out the upper 32bit of the address. This has no effect for most programs, but for large programs which use more then 4GB of memory, it will lead to suprise crashes. IMPORTANT: The valgrind check only happens for types with private data. Adding NVALGRIND=1 to the compiler defines disables valgrind support and fixes the problem. Version-Release number of selected component (if applicable): mingw64-glib2-2.38.2-1.fc20 How reproducible: always Steps to Reproduce: 1. Use loads of memory 2. create a GTypeInstance (with private data or the bug won't trigger) at an address > 4GB. Most GObject types should also work 3. free the instance with g_type_free_instance (or g_object_unref) 4. -> crash
This is an excellent bug report, thank you! Do you think you could report it upstream at https://bugzilla.gnome.org/enter_bug.cgi?product=glib to make sure the upstream glib people are aware of the issue? I could do it too, but if you could it would be great, since you understand the issue best. We can definitely disable Valgrind support if there's no other solution, but let's see what upstream has to say first. Thanks!
I did spend some time to track down the root problem of the crash. Basically, updating glib/valgrind.h should do the trick. I did also create a gnome bugzilla entry, more details there. It would be nice, if an fix could find it's way into fedora 20.
I'm not clear how we can solve this in Fedora, since AFAICT our %mingw_configure macro does not allow us to append values to CFLAGS.
As I wrote in the gnome bugzilla, the actual problem is in glib/valgrind.h. Updating it to the latest version from valgrind upstream (at least SVN r13971) should fix the problem. AFAIK, this can be done with a patch in the rpm package.
Where is glib's subversion repository? I only see a git repo. Can you link to the actual patch I need to apply.
I was referring to the valgrind subversion repository, sorry if my message was confusing. You need to replace the glib/valgrind.h file from glib with an newer version from valgrind (located in include/valgrind.h in the valgrind source tree). The file isn't updated in upstream glib yet, see the linked gnome bugzilla entry. You can find the file on a github mirrow here: https://github.com/lu-zero/valgrind/blob/master/include/valgrind.h
To test: I built mingw-glib2 with the updated valgrind.h on my local machine, installed it, and used that to build mingw-gtk2. I ran the gtk demo under Wine. I examined the valgrind.h diff. Mainly it appears to be adding aarch64 support, but it also contains what looks like a relevant fix for this bug. This all appeared to be successful (I'm not clear how good this test is however). I will push an update to Fedora 20. Please test it carefully.
mingw-glib2-2.40.0-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mingw-glib2-2.40.0-2.fc20
Richard, here are the relevant upstream patches: svn r13513 (original fix from upstream bug[1]) https://github.com/lu-zero/valgrind/commit/9add17ad7112a9d56d5f0dfe91dec35407aa8b55 svn r13971 (original fix was incorrectly ordered) https://github.com/lu-zero/valgrind/commit/c93e021d4eb0871224f4e225bdf0531f4e8cc81d [1] https://bugs.kde.org/show_bug.cgi?id=323912 Bernhard, for future reference, please link to any upstream bug reports, mailing list posts, or patches directly.
Package mingw-glib2-2.40.0-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mingw-glib2-2.40.0-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6441/mingw-glib2-2.40.0-2.fc20 then log in and leave karma (feedback).
Please test the package. It will not go into Fedora until you have tested it and ensured it works.
Sorry for the delay. I verified that the correct x64 assembly instructions are used and a quick test didn't show any additional problems, so as far as I can see, the bug is fixed.
mingw-glib2-2.40.0-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.