shmem_win32 possible bug
GCC for 32-bit and 64-bit Windows with a real installer & updater
Brought to you by:
tdragon
Menu
▾
▴
#265 shmem_win32 possible bug
Started getting random problems building stuff that works on a similar gcc-4.9.2 version without the shmem patch. gcc itself builds fine with a gcc patched with the shmem implementation, but QT5 among others start behaving rather odly. I also noticed that some projects start throwing segmentation faults inconsistently -> sometimes it happens with a 64 bit build other times it happens on a 32 bit build but when it happens its consistent for that build arch. Im no guru with gdb but i did manage to have it spit out a location in the __shmem_grab function at some point so i suspect something might need attention there ?.
might also explain some of the problems the other users have reported here.
Related
Discussion
Anonymous
I know its not really the most detailed report, it's a bit random when
it fails so it has been hard to get data on what might cause the shmem
code to keel over. Im trying out a few things atm to see if i can gather
a stack trace maybe that will help.
Den 14-06-2015 kl. 15:32 skrev John E.:
Related
Bugs: #265
Registers:
eax=00000000 ebx=00000003 ecx=00000000 edx=00000000 esi=770c2100
edi=770c20c0
eip=76fdfd0e esp=0028fa60 ebp=0028fa7c iopl=0 nv up ei pl zr na
po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
AddrPC Params
76FDFD0E 00000000 77E8F3B0 FFFFFFFF ntdll.dll!NtTerminateProcess
766179DD 00000003 0028FAD4 749E3372 kernel32.dll!ExitProcess
749E36DC 00000003 83F9C8DA 005F0E78 msvcrt.dll!exit
749E3372 00000003 00000001 00000000 msvcrt.dll!dup
74A3B2F1 00000003 004050C8 40000015 msvcrt.dll!exit
74A38F7B 6E9704E4 00000000 0028FE6C msvcrt.dll!abort
6E953F27 83F9CCBA 00000020 005F1AF8
libgcc_s_dw2-1.dll!__deregister_frame_info_bases
[E:\mingw-w64-gcc\src\build-i686-w64-mingw32\i686-w64-mingw32\libgcc/../../../gcc-4.9.2/libgcc/unwind-dw2-fde.c
@ 222]
749DC3E9 00000000 00000000 00000000 msvcrt.dll!isspace
749E36BB 00000000 005F1AF8 005F23E8 msvcrt.dll!exit
004014B3 7EFDE000 0028FFD4 76FF92E2 python2.exe!0x14b3
7661337A 7EFDE000 7E7741CC 00000000 kernel32.dll!BaseThreadInitThunk
76FF92E2 004014E0 7EFDE000 00000000 ntdll.dll!RtlInitializeExceptionChain
76FF92B5 004014E0 7EFDE000 00000000 ntdll.dll!RtlInitializeExceptionChain
example of the crash that occurs, seems like the crash happens in
unwind-dw2-fde.c line 222
int the function __deregister_frame_info_bases where it seems to hit
this assert -> gcc_assert (ob);
this does not happen in a gcc without the shmem patch.
Hope it helps.
Nailed the problem.
Its a known problem which also affected cygwin dwarf builds some time
back, they admitted a patch to the gcc folks which got accepted, but
something seems to have changed in later code causing gcc_assert to fail
being optimized out in release builds.
a temporary fix is to enclose the asserts in unwind_dw2_fde.c in #if
defined(_DEBUG) gcc_assert(something to check) #endif
this is a hacky way to get around the problem but it works, everything
builds without error now.
Ill file a bug report to the gcc folks.
Last edit: ralph engels 2015-06-19
Not a very helpful bug report...
I found the problem affecting some builds and posted the fix, theres still one bugger to hunt down which causes QT5 to segfault when linked to the static gcc runtime even with this fix. I have a compounded patch containing all the fixes against gcc-4.9.2 + your patchset, and my fix for the build error in dwarf builds. I added it as an attachment.
Last edit: ralph engels 2015-06-20
Thanks for tracking all of these patch hunks down! I am definitely interested in incorporating them all in the next TDM release. (Some of them already have been, in fact!)
Would you be able to point me toward the authorship and explanations for:
the Graphite changes, and
the intl/* changes?
libcpp/files.c - Purposefully rejecting relative paths with a nonexistent directory component - what does this fix in practice?
libgcc/unwind-dw2-fde.c - Are all these asserts being incorrectly triggered at runtime, or is it just one?
libstdc++-v3/config/abi/pre/gnu.ver - What does exporting these additional globals fix?
patches are from the Msys2 project.
the intl changes are for relocation, originally from the gnuwin32 patchset i believe.
the graphite changes are to allow gcc-4.9.2 to work with the latest isl.
most of the others from the msys2 project are for bugs discovered after the release of gcc-4.9.2.
the stdc++ one is for exporting some globals that where missing in libstdc++.
unwind-dw2-fde.c so far only one so it might be overkill.
void
__deregister_frame_info_bases (const void begin)
{
struct object *p;
struct object ob = 0;
/ If .eh_frame is empty, we haven't registered. /
if ((const uword ) begin == 0 || (const uword *) begin == 0)
return ob;
init_object_mutex_once ();
__gthread_mutex_lock (&object_mutex);
for (p = &unseen_objects; p ; p = &(p)->next)
if ((p)->u.single == begin)
{
ob = p;
*p = ob->next;
goto out;
}
for (p = &seen_objects; p ; p = &(p)->next)
if ((p)->s.b.sorted)
{
if ((p)->u.sort->orig_data == begin)
{
ob = p;
p = ob->next;
free (ob->u.sort);
goto out;
}
}
else
{
if ((p)->u.single == begin)
{
ob = p;
*p = ob->next;
goto out;
}
}
out:
__gthread_mutex_unlock (&object_mutex);
gcc_assert (ob); // not being optimized out in release builds, causes the runtime to terminate abnormally.
return (void *) ob;
}
the commented section above is where the debugger pointed me at.
link to the original patchset here
http://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources/mingw-w64-i686-gcc-4.9.2-5.src.tar.gz/download
Not all of the included ones are used, look in the PKGBUILD file to see which are needed.
Last edit: ralph engels 2015-06-21
Yep, some of the patches are obviously useful and some less so. I probably won't be incorporating the intl relocation additions, the libcpp/files.c change, or the libstdc++ gnu.ver change, unless I can get some more detail on where they originated and what they purport to fix. I'd also be interested to see if you can point me to where you identified the known problem affecting Cygwin DW2 builds for the justification in commenting out the gcc_assert.
The DW2 build problem was believed to be fixed with an old cygwin commit from here
https://sourceware.org/ml/cygwin/2013-07/msg00528.html
and this is pretty much how the gcc-4.9.2 code looks now, sadly it seems something else has turned up and broken it again. My fix is just a temporary workaround untill someone
figures out what went wrong. It mostly affects building python but a few other packages also had problems before my little hack so i firmly believe it to be a compiler bug in general and not related to your patchset.
After reading a bit into the libcpp/files.c part it seems to be an msys2 specific fix for symlinks so might not be of interrest to you unless you plan on shifting your build environment.
the gnu.ver change was from a bugreport by ruben because of a PECOFF change. It can be found here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
I agree with the relocation patch it seems superflous if using external gettext with the same fix, i guess alexy left it in for those who wanted to make a cross compiler with minimum dependencies.
Excellent, thanks again for all your research into this. The next TDM-GCC release will include the following new patches:
- [lto-binary.patch] LTO open files in binary mode
- [xmmintrin.patch] C++ guards for xmmintrin.h
- [gnat-implibs.patch] Create DLL import libs for libgnat and libgnarl
- [mcrtdll.patch] Allow specifying MSVCRT version with -mcrtdll=
- [dw2-reg-frame.patch] Prevent DW2 frame register/unregister from being stripped
Also, for now I'm commenting out the single gcc_assert(ob) that seems to cause problems in unwind-dw2-fde.c; this hunk will go in eh_shmem.patch.
The rest of the hunks in the posted patch I'm omitting because they (A) are already fixed or superseded upstream, or (B) aren't necessary for the native TDM-GCC environment.
Np m8, and thanks for all your work on TDM.
Going to the MSYS2 sources (REPOS/MINGW/Sources) is a strange way to get our patches. Those tarballs exist for license compliance reasons and not primarily as resources for other developers.
You can save yourselves some effort if you go to where our development work happens, for example:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc-git
Thanks Ray.
Aye the main branch would be a better place to look, allthough most of the patches seem to have the same content that might very well change from version to version.