Created attachment 514714 [details] screenshot Greetings all, I have come across the following bug in glibc - I was running a 32-bit ELF when the SIGSEGV occured, I am not sure if this impacts 64-bit. I am also not sure whether this is a glibc or a gcc bug. I am running gcc-7.2.0 The __strpbrk_sse42 function uses the `movaps` SSE4.2 instruction, but the stack pointer is not guaranteed to be on a 16 byte alignment - as it was in my case. Please see the attached screenshot with the bug in action. Please contact me via e-mail for a copy of the offending binary. I have also attached `emerge --info` for the stable glibc (2.25-r9 as of writing) and the latest unstable one (2.26-r5 as of writing) as well; the bug surfaces in both releases. stable glibc: https://paste.pound-python.org/show/DiHMM70ymdJn4J2Sfn8V/ unstable glibc: https://paste.pound-python.org/show/jIcMd8NJB5R1pmcrjHs3/ I was able to run the same program without crashing on another system with a newer generation CPU, this could perhaps be attributed to it using AVX instructions instead of SSE4.2. A quite similar (if not the same) bug can be found on the Arch bug tracker: https://bugs.archlinux.org/task/541364
(In reply to vista from comment #0) > Created attachment 514714 [details] > screenshot > > Greetings all, > > I have come across the following bug in glibc - I was running a 32-bit ELF > when the SIGSEGV occured, I am not sure if this impacts 64-bit. I am also > not sure whether this is a glibc or a gcc bug. I am running gcc-7.2.0 > > The __strpbrk_sse42 function uses the `movaps` SSE4.2 instruction, but the > stack pointer is not guaranteed to be on a 16 byte alignment - as it was in > my case. > > Please see the attached screenshot with the bug in action. Please contact me > via e-mail for a copy of the offending binary. Do you have a minimal source-based reproducer instead and attach it here? Or can you write one? What does [esp] hold? I guess an unaligned pointer to the string you passed in. Is it valid? > I have also attached `emerge --info` for the stable glibc (2.25-r9 as of > writing) and the latest unstable one (2.26-r5 as of writing) as well; the > bug surfaces in both releases. > stable glibc: https://paste.pound-python.org/show/DiHMM70ymdJn4J2Sfn8V/ > unstable glibc: https://paste.pound-python.org/show/jIcMd8NJB5R1pmcrjHs3/ Please attach emerge --info output to the bug. > I was able to run the same program without crashing on another system with a > newer generation CPU, this could perhaps be attributed to it using AVX > instructions instead of SSE4.2. > > A quite similar (if not the same) bug can be found on the Arch bug tracker: > https://bugs.archlinux.org/task/541364 Says "task does not exist".
Created attachment 514716 [details] stable-glibc info
glibc's implementation of __strpbrk_sse42 for 32/64-bit x86 should be here: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strcspn-c.c;h=857af10486032455a0cbfee0abb97b3c28911018;hb=HEAD#l82 Maybe you'll be able to trace it on your local system and spot what generated unaligned access.
Created attachment 514718 [details] unstable-glibc info
(In reply to Sergei Trofimovich from comment #1) > Do you have a minimal source-based reproducer instead and attach it here? Or > can you write one? > What does [esp] hold? I guess an unaligned pointer to the string you passed > in. > Is it valid? I was trying to create a test-case, but I had no success in the end - the executable/binary I had problems with are "alien" to my system, they were compiled with with a gcc version that's more than a decade old. I had no problems running them on my newer system (which supports AVX/AVX2), though. > Please attach emerge --info output to the bug. Done. > > A quite similar (if not the same) bug can be found on the Arch bug tracker: > > https://bugs.archlinux.org/task/541364 > > Says "task does not exist". There is indeed a typo in the URL, the correct one is: https://bugs.archlinux.org/task/54136
(In reply to Sergei Trofimovich from comment #3) > glibc's implementation of __strpbrk_sse42 for 32/64-bit x86 should be here: > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/ > strcspn-c.c;h=857af10486032455a0cbfee0abb97b3c28911018;hb=HEAD#l82 > > Maybe you'll be able to trace it on your local system and spot what > generated unaligned access. I will try to trace it tomorrow
(In reply to vista from comment #5) > I was trying to create a test-case, but I had no success in the end - the > executable/binary I had problems with are "alien" to my system, they were > compiled with with a gcc version that's more than a decade old. Oh, that might might explain it. GCC (before 4.5) used to assume stack alignment=16 on i386 when SSE was introduced and fixed since. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 for historical reference. It might or might not be the issue you are experiencing. Depends on how callbacks into glibc and back happen in your program. The workarounds to check the theory could be (any of): - rebuild old binary with new compiler to apply according stack alignment - rebuild glibc with -mstackrealign (might be tricky). That will cause every C function in glibc to autorealign stack.
(In reply to Sergei Trofimovich from comment #7) > (In reply to vista from comment #5) > > I was trying to create a test-case, but I had no success in the end - the > > executable/binary I had problems with are "alien" to my system, they were > > compiled with with a gcc version that's more than a decade old. > > Oh, that might might explain it. > > GCC (before 4.5) used to assume stack alignment=16 on i386 when SSE was > introduced and fixed since. See > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 > for historical reference. > > It might or might not be the issue you are experiencing. Depends on how > callbacks into glibc and back happen in your program. > > The workarounds to check the theory could be (any of): > - rebuild old binary with new compiler to apply according stack alignment > - rebuild glibc with -mstackrealign (might be tricky). That will cause every > C function in glibc to autorealign stack. I see. Sadly, this binary is one of those legacy applications where the vendor's not even around anymore. I'll spin up a VM in the following week and test the latter solution.
Another thing to check is building glibc against recently added gcc-7.3.0. I've encountered https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481 when scrolling through changelog. Looks very similar as well.
Any news here?
(In reply to Andreas K. Hüttel from comment #10) > Any news here? Hey Andreas, I did not have time to properly debug this in the end, I managed to find a bit older version of the application which did not exhibit this behaviour. Thanks, vista
