GNOME Bugzilla – Bug 730198
broken valgrind.h leads to crashes in g_type_free_instance on mingw64
Last modified: 2014-06-30 09:49:31 UTC
The version of the valgrind.h file included with current glib doesn't have mingw64 support. As the mingw64 gcc also defines __MINGW32__, this doesn't result in a compile error, instead the 32bit version of the inline assembly is used, and the upper 32bit of the rbx register will be zeroed every time a valgrind function is called. The result are for example crashes in g_type_free_instance, if a GInstance beyond the 4GB boundary is freed. As an important note, you need at least SVN revision r13971, the mingw64 support in earlier versions is buggy.
Here's the upstream bug, which was fixed in r13513. https://bugs.kde.org/show_bug.cgi?id=323912
This bug does NOT fix the problem. If you look at the patch, it adds the defined(__MINGW64__) check after the defined(__MINGW32__) check. As the mingw64 gcc defines both symbols, the defined(__MINGW64__) is never reached. You need at least svn revision r13971.
Created attachment 276666 [details] [review] update to latest valgrind.h The attached patch updates valgrind.h to the latest upstream version from SVN. It is important to bear in mind the side effects of that, which are segfaults when running old (only on PPC32, from what I understand) binaries under Valgrind with a new GLib, discussed in upstream Bugzilla: https://bugs.kde.org/show_bug.cgi?id=278808#c5
I'm OK with the update as long as the PPC issue is fixed. Thanks.
Comment on attachment 276666 [details] [review] update to latest valgrind.h Pushed to master, thanks!
Oh, and if I was not clear about the PPC issue, the upstream bug suggests that even without the changes in the patch, a crash would still occur on PPC with a new Valgrind when the binary was compiled against an old valgrind.h from GLib. Should this also go on the glib-2-40 branch?
Hi, Unfortunately this breaks the build of gslice.c on x64 Visual C++ builds, as the latest valgrind.h does not support Visual C++ in x64 mode (#error "Unsupported compiler", since x64 Visual C++ does not support inline assembly, unlike x86 Visual C++). With blessings, thanks for the notice.
Sounds like you should get MSFT to fix their compiler. It's kind of unbelievable that they don't support inline assembly, but it appears to be true: https://stackoverflow.com/questions/1295452/why-does-msvc-not-support-inline-assembly-for-amd64-and-itanium-targets http://msdn.microsoft.com/en-us/library/wbk4z78b.aspx
Hi, I have opened a bug, 732465, to disable the use of features from valigrind.h by defining NVALGRIND when building GLib with x64 Visual C++, for record's purposes. ----------- Hi Richard, That is something that they discourage people from doing, so they only support it for x86 builds, for copmatibility's sake. So I don't think they would change on that decision. So, although I do appreciate the suggestions you have here, but I doubt that it is going to be feasible. http://stackoverflow.com/questions/6166437/64bit-applications-and-inline-assembly As valgrind.h is essentially third party code that's included in GLib, we have to work around that here, or try to find a way to use compiler intrinsics to implement the items and submit a patch to the valgrind project. ------------ With blessings, thank you!