Some apss, not only steam, stop working after glibc upgrade to 2.18 due to removing "inline" from __m128i function. This changes incorporated after commit f1d70dad5381352b3cad04b5ee0dd0efe2627683 (see https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/x86_64/multiarch/strstr.c;h=cd63b68c01e88d7bfe4eda77a65e370d8a417b86;hp=1cc015d0c198a139bb2b8bbc88780f2b08f4abdc;hb=f1d70dad5381352b3cad04b5ee0dd0efe2627683;hpb=7bd642f580ef5698bd5b1777a5ba7af2f58c5d8c) Reproducible: Always Steps to Reproduce: 1. unmask and add keyword to glibc 2. emerge -1 =sys-libs/glibc-2.18 3. steam segfaults in libc.so.6 and libGL.so.1
Created attachment 361552 [details, diff] revert a part of commit This patch works for me.
I'd mark this UPSTREAM (for steam that is, not glibc) if it weren't already a duplicate. Reverting sys-libs/glibc changes because of proprietary clients that we do not support in the official tree (yet) is a bit far-fetched, though. *** This bug has been marked as a duplicate of bug 442176 ***
Actually this may be closed prematurely and I don't think it is a dupe. Reverting the upstream patch does in fact allow acroread to work again. app-text/acroread faults has been observed to fault with this stack on glibc-2.18 .... (gdb) bt #0 0xf5aaefcd in __strstr_sse42 () from /lib32/libc.so.6 #1 0xf5b62f10 in _XlcMapOSLocaleName () from /usr/lib32/libX11.so.6 #2 0xf5b85c80 in _XOpenLC () from /usr/lib32/libX11.so.6 #3 0xf5b85d4c in _XlcCurrentLC () from /usr/lib32/libX11.so.6 #4 0xf5b85e14 in XSupportsLocale () from /usr/lib32/libX11.so.6 #5 0xf5ed7f93 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0 #6 0xf5edcfe4 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0 #7 0xf5e9291a in gdk_pre_parse_libgtk_only () from /usr/lib32/libgdk-x11-2.0.so.0 #8 0xf605e977 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0 #9 0xf5cbde8a in g_option_context_parse () from /usr/lib32/libglib-2.0.so.0 #10 0xf605ec78 in gtk_parse_args () from /usr/lib32/libgtk-x11-2.0.so.0 #11 0xf605ed03 in gtk_init_check () from /usr/lib32/libgtk-x11-2.0.so.0 #12 0xf605ed43 in gtk_init () from /usr/lib32/libgtk-x11-2.0.so.0 #13 0x0850d9e7 in _start () (gdb) info registers eax 0xf5bd0f51 -172159151 ecx 0x10 16 edx 0xcd0 3280 ebx 0xf5c65000 -171552768 esp 0xffb16cb4 0xffb16cb4 ebp 0xab0dcf0 0xab0dcf0 esi 0xab0dcd0 179363024 edi 0xab0dcd0 179363024 eip 0xf5aaefcd 0xf5aaefcd <__strstr_sse42+861> eflags 0x10202 [ IF RF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99 (gdb) disassemble Dump of assembler code for function __strstr_sse42: 0xf5aaec70 <+0>: push %ebp 0xf5aaec71 <+1>: push %edi 0xf5aaec72 <+2>: push %esi 0xf5aaec73 <+3>: sub $0x30,%esp 0xf5aaec76 <+6>: mov 0x44(%esp),%eax 0xf5aaec7a <+10>: movzbl (%eax),%edx 0xf5aaec7d <+13>: test %dl,%dl 0xf5aaec7f <+15>: je 0xf5aaefc0 <__strstr_sse42+848> 0xf5aaec85 <+21>: mov 0x40(%esp),%eax 0xf5aaec89 <+25>: movzbl (%eax),%eax 0xf5aaec8c <+28>: test %al,%al 0xf5aaec8e <+30>: je 0xf5aaeffe <__strstr_sse42+910> 0xf5aaec94 <+36>: mov 0x40(%esp),%edi 0xf5aaec98 <+40>: cmpb $0x0,0x1(%edi) 0xf5aaec9c <+44>: je 0xf5aaefe8 <__strstr_sse42+888> 0xf5aaeca2 <+50>: mov 0x40(%esp),%eax 0xf5aaeca6 <+54>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaecab <+59>: mov 0x44(%esp),%eax 0xf5aaecaf <+63>: movdqa %xmm0,%xmm2 0xf5aaecb3 <+67>: cmpb $0x0,0x1(%eax) 0xf5aaecb7 <+71>: jne 0xf5aaefcd <__strstr_sse42+861> 0xf5aaecbd <+77>: mov 0x44(%esp),%eax 0xf5aaecc1 <+81>: pxor %xmm1,%xmm1 0xf5aaecc5 <+85>: pinsrb $0x0,(%eax),%xmm1 0xf5aaeccb <+91>: movdqa %xmm1,(%esp) 0xf5aaecd0 <+96>: movdqa (%esp),%xmm1 0xf5aaecd5 <+101>: mov $0x0,%edi 0xf5aaecda <+106>: mov $0x0,%edx 0xf5aaecdf <+111>: pcmpistri $0xc,%xmm2,%xmm1 0xf5aaece5 <+117>: sete %al 0xf5aaece8 <+120>: setb %dl 0xf5aaeceb <+123>: movzbl %al,%eax 0xf5aaecee <+126>: mov %eax,0x2c(%esp) 0xf5aaecf2 <+130>: mov %edi,%eax 0xf5aaecf4 <+132>: sets %al 0xf5aaecf7 <+135>: mov %eax,%edi 0xf5aaecf9 <+137>: test %edx,%edi 0xf5aaecfb <+139>: je 0xf5aaed68 <__strstr_sse42+248> 0xf5aaecfd <+141>: pxor %xmm0,%xmm0 0xf5aaed01 <+145>: add %ecx,0x40(%esp) 0xf5aaed05 <+149>: pcmpeqb %xmm1,%xmm0 0xf5aaed09 <+153>: pmovmskb %xmm0,%ebp 0xf5aaed0d <+157>: bsf %ebp,%ebp 0xf5aaed10 <+160>: lea 0x0(%ebp,%ecx,1),%eax 0xf5aaed14 <+164>: mov 0x40(%esp),%esi 0xf5aaed18 <+168>: cmp $0x10,%eax 0xf5aaed1b <+171>: jg 0xf5aaed26 <__strstr_sse42+182> 0xf5aaed1d <+173>: add $0x30,%esp 0xf5aaed20 <+176>: mov %esi,%eax 0xf5aaed22 <+178>: pop %esi 0xf5aaed23 <+179>: pop %edi 0xf5aaed24 <+180>: pop %ebp 0xf5aaed25 <+181>: ret 0xf5aaed26 <+182>: mov %esi,%eax 0xf5aaed28 <+184>: movdqa %xmm1,0x10(%esp) 0xf5aaed2e <+190>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaed33 <+195>: movdqa 0x10(%esp),%xmm1 0xf5aaed39 <+201>: pcmpistri $0xc,%xmm0,%xmm1 0xf5aaed3f <+207>: sets %al 0xf5aaed42 <+210>: setb %dl 0xf5aaed45 <+213>: movzbl %al,%eax 0xf5aaed48 <+216>: mov %ecx,0x10(%esp) 0xf5aaed4c <+220>: movzbl %dl,%edx 0xf5aaed4f <+223>: mov %eax,%edi 0xf5aaed51 <+225>: sete %al 0xf5aaed54 <+228>: add %ecx,%ebp 0xf5aaed56 <+230>: movzbl %al,%eax 0xf5aaed59 <+233>: add %ecx,%esi 0xf5aaed5b <+235>: cmp $0x10,%ebp 0xf5aaed5e <+238>: mov %eax,0x2c(%esp) 0xf5aaed62 <+242>: jle 0xf5aaed1d <__strstr_sse42+173> 0xf5aaed64 <+244>: lea 0x0(%esi,%eiz,1),%esi 0xf5aaed68 <+248>: test %edi,%edi 0xf5aaed6a <+250>: jne 0xf5aaef31 <__strstr_sse42+705> 0xf5aaed70 <+256>: mov 0x44(%esp),%eax 0xf5aaed74 <+260>: movl $0x0,0x10(%esp) 0xf5aaed7c <+268>: add $0x10,%eax 0xf5aaed7f <+271>: test %edx,%edx 0xf5aaed81 <+273>: mov %eax,0x28(%esp) 0xf5aaed85 <+277>: mov 0x2c(%esp),%eax 0xf5aaed89 <+281>: je 0xf5aaef1e <__strstr_sse42+686> 0xf5aaed8f <+287>: nop 0xf5aaed90 <+288>: test %ecx,%ecx 0xf5aaed92 <+290>: jne 0xf5aaefa0 <__strstr_sse42+816> 0xf5aaed98 <+296>: test %eax,%eax 0xf5aaed9a <+298>: jne 0xf5aaefc0 <__strstr_sse42+848> 0xf5aaeda0 <+304>: mov 0x40(%esp),%eax 0xf5aaeda4 <+308>: lea 0x10(%eax),%esi 0xf5aaeda7 <+311>: mov 0x28(%esp),%eax 0xf5aaedab <+315>: mov %eax,%edi 0xf5aaedad <+317>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaedb2 <+322>: movdqa %xmm0,(%esp) 0xf5aaedb7 <+327>: mov %esi,%eax 0xf5aaedb9 <+329>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaedbe <+334>: movdqa (%esp),%xmm1 0xf5aaedc3 <+339>: movdqa %xmm0,%xmm4 0xf5aaedc7 <+343>: pcmpistri $0xc,%xmm0,%xmm1 0xf5aaedcd <+349>: sete %dl 0xf5aaedd0 <+352>: sets %al 0xf5aaedd3 <+355>: movzbl %dl,%edx 0xf5aaedd6 <+358>: mov %ecx,%ebp 0xf5aaedd8 <+360>: movzbl %al,%eax 0xf5aaeddb <+363>: or %edx,%ecx 0xf5aaeddd <+365>: or %eax,%ecx 0xf5aaeddf <+367>: jne 0xf5aaee26 <__strstr_sse42+438> 0xf5aaede1 <+369>: lea 0x0(%esi,%eiz,1),%esi 0xf5aaede8 <+376>: add $0x10,%edi 0xf5aaedeb <+379>: add $0x10,%esi 0xf5aaedee <+382>: mov %edi,%eax 0xf5aaedf0 <+384>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaedf5 <+389>: mov %esi,%eax 0xf5aaedf7 <+391>: movdqa %xmm0,(%esp) 0xf5aaedfc <+396>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaee01 <+401>: movdqa (%esp),%xmm1 0xf5aaee06 <+406>: movdqa %xmm0,%xmm4 0xf5aaee0a <+410>: pcmpistri $0xc,%xmm0,%xmm1 0xf5aaee10 <+416>: sete %dl 0xf5aaee13 <+419>: sets %al 0xf5aaee16 <+422>: movzbl %dl,%edx 0xf5aaee19 <+425>: mov %ecx,%ebp 0xf5aaee1b <+427>: movzbl %al,%eax 0xf5aaee1e <+430>: or %edx,%ebp 0xf5aaee20 <+432>: or %eax,%ebp 0xf5aaee22 <+434>: je 0xf5aaede8 <__strstr_sse42+376> 0xf5aaee24 <+436>: mov %ecx,%ebp 0xf5aaee26 <+438>: test %ebp,%ebp 0xf5aaee28 <+440>: sete %cl 0xf5aaee2b <+443>: movzbl %cl,%esi 0xf5aaee2e <+446>: test %eax,%esi 0xf5aaee30 <+448>: jne 0xf5aaefc0 <__strstr_sse42+848> 0xf5aaee36 <+454>: test %edx,%edx 0xf5aaee38 <+456>: je 0xf5aaefb8 <__strstr_sse42+840> 0xf5aaee3e <+462>: test %eax,%eax 0xf5aaee40 <+464>: je 0xf5aaeffe <__strstr_sse42+910> 0xf5aaee46 <+470>: movdqa (%esp),%xmm2 0xf5aaee4b <+475>: movdqa %xmm4,%xmm0 0xf5aaee4f <+479>: pxor %xmm1,%xmm1 0xf5aaee53 <+483>: pcmpeqb %xmm1,%xmm0 0xf5aaee57 <+487>: pcmpeqb %xmm1,%xmm2 0xf5aaee5b <+491>: pmovmskb %xmm0,%eax 0xf5aaee5f <+495>: pmovmskb %xmm2,%edx 0xf5aaee63 <+499>: bsf %eax,%eax 0xf5aaee66 <+502>: bsf %edx,%edx 0xf5aaee69 <+505>: cmp %eax,%edx 0xf5aaee6b <+507>: jge 0xf5aaeffe <__strstr_sse42+910> 0xf5aaee71 <+513>: mov 0x44(%esp),%eax 0xf5aaee75 <+517>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaee7a <+522>: mov 0x10(%esp),%eax 0xf5aaee7e <+526>: movdqa %xmm0,(%esp) 0xf5aaee83 <+531>: test %eax,%eax 0xf5aaee85 <+533>: jne 0xf5aaeee0 <__strstr_sse42+624> 0xf5aaee87 <+535>: movdqa %xmm0,%xmm3 0xf5aaee8b <+539>: movl $0x10,0x10(%esp) 0xf5aaee93 <+547>: movdqa %xmm3,%xmm1 0xf5aaee97 <+551>: punpcklbw %xmm3,%xmm0 0xf5aaee9b <+555>: punpcklbw %xmm0,%xmm0 0xf5aaee9f <+559>: psrldq $0x1,%xmm1 0xf5aaeea4 <+564>: pshufd $0x0,%xmm0,%xmm0 0xf5aaeea9 <+569>: pcmpeqb %xmm1,%xmm0 0xf5aaeead <+573>: pmovmskb %xmm0,%eax 0xf5aaeeb1 <+577>: bsf %eax,%edx 0xf5aaeeb4 <+580>: test %eax,%eax 0xf5aaeeb6 <+582>: je 0xf5aaeee0 <__strstr_sse42+624> 0xf5aaeeb8 <+584>: cmp $0x7fff,%eax 0xf5aaeebd <+589>: movl $0x1,0x10(%esp) 0xf5aaeec5 <+597>: je 0xf5aaeee0 <__strstr_sse42+624> 0xf5aaeec7 <+599>: lea 0x1(%edx),%eax 0xf5aaeeca <+602>: mov $0x3,%edi 0xf5aaeecf <+607>: test %edx,%edx 0xf5aaeed1 <+609>: cmove %edi,%eax 0xf5aaeed4 <+612>: mov %eax,0x10(%esp) 0xf5aaeed8 <+616>: nop 0xf5aaeed9 <+617>: lea 0x0(%esi,%eiz,1),%esi 0xf5aaeee0 <+624>: mov 0x10(%esp),%eax 0xf5aaeee4 <+628>: cmp %ebp,%eax 0xf5aaeee6 <+630>: cmovle %eax,%ebp 0xf5aaeee9 <+633>: add %ebp,0x40(%esp) 0xf5aaeeed <+637>: mov 0x40(%esp),%eax 0xf5aaeef1 <+641>: cmpb $0x0,(%eax) 0xf5aaeef4 <+644>: je 0xf5aaeffe <__strstr_sse42+910> 0xf5aaeefa <+650>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaeeff <+655>: movdqa (%esp),%xmm1 0xf5aaef04 <+660>: pcmpistri $0xc,%xmm0,%xmm1 0xf5aaef0a <+666>: setb %dl 0xf5aaef0d <+669>: sete %al 0xf5aaef10 <+672>: movzbl %dl,%edx 0xf5aaef13 <+675>: movzbl %al,%eax 0xf5aaef16 <+678>: test %edx,%edx 0xf5aaef18 <+680>: jne 0xf5aaed90 <__strstr_sse42+288> 0xf5aaef1e <+686>: test %eax,%eax 0xf5aaef20 <+688>: jne 0xf5aaeffe <__strstr_sse42+910> 0xf5aaef26 <+694>: addl $0x10,0x40(%esp) 0xf5aaef2b <+699>: mov 0x40(%esp),%eax 0xf5aaef2f <+703>: jmp 0xf5aaeefa <__strstr_sse42+650> 0xf5aaef31 <+705>: mov 0x2c(%esp),%esi 0xf5aaef35 <+709>: test %esi,%esi 0xf5aaef37 <+711>: jne 0xf5aaf00f <__strstr_sse42+927> 0xf5aaef3d <+717>: mov 0x40(%esp),%esi 0xf5aaef41 <+721>: jmp 0xf5aaef50 <__strstr_sse42+736> 0xf5aaef43 <+723>: nop 0xf5aaef44 <+724>: lea 0x0(%esi,%eiz,1),%esi 0xf5aaef48 <+728>: test %eax,%eax 0xf5aaef4a <+730>: jne 0xf5aaf009 <__strstr_sse42+921> 0xf5aaef50 <+736>: add %ecx,%esi 0xf5aaef52 <+738>: movdqa %xmm1,(%esp) 0xf5aaef57 <+743>: mov %esi,%eax 0xf5aaef59 <+745>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaef5e <+750>: movdqa (%esp),%xmm1 0xf5aaef63 <+755>: pcmpistri $0xc,%xmm0,%xmm1 0xf5aaef69 <+761>: setb %al 0xf5aaef6c <+764>: movzbl %al,%eax 0xf5aaef6f <+767>: mov %eax,%ebp 0xf5aaef71 <+769>: mov $0x0,%eax 0xf5aaef76 <+774>: sete %al 0xf5aaef79 <+777>: xor %edx,%edx 0xf5aaef7b <+779>: test %ecx,%ecx 0xf5aaef7d <+781>: sete %dl 0xf5aaef80 <+784>: mov %edx,%edi 0xf5aaef82 <+786>: test %ebp,%edi 0xf5aaef84 <+788>: je 0xf5aaef48 <__strstr_sse42+728> 0xf5aaef86 <+790>: mov %esi,0x40(%esp) 0xf5aaef8a <+794>: xor %ecx,%ecx 0xf5aaef8c <+796>: mov 0x40(%esp),%esi 0xf5aaef90 <+800>: add $0x30,%esp 0xf5aaef93 <+803>: add %ecx,%esi 0xf5aaef95 <+805>: mov %esi,%eax 0xf5aaef97 <+807>: pop %esi 0xf5aaef98 <+808>: pop %edi 0xf5aaef99 <+809>: pop %ebp 0xf5aaef9a <+810>: ret 0xf5aaef9b <+811>: nop 0xf5aaef9c <+812>: lea 0x0(%esi,%eiz,1),%esi 0xf5aaefa0 <+816>: mov 0x40(%esp),%esi 0xf5aaefa4 <+820>: mov 0x44(%esp),%edi 0xf5aaefa8 <+824>: add %ecx,%esi 0xf5aaefaa <+826>: mov %esi,0x40(%esp) 0xf5aaefae <+830>: jmp 0xf5aaedb7 <__strstr_sse42+327> 0xf5aaefb3 <+835>: nop 0xf5aaefb4 <+836>: lea 0x0(%esi,%eiz,1),%esi 0xf5aaefb8 <+840>: test %cl,%cl 0xf5aaefba <+842>: je 0xf5aaee71 <__strstr_sse42+513> 0xf5aaefc0 <+848>: mov 0x40(%esp),%esi 0xf5aaefc4 <+852>: add $0x30,%esp 0xf5aaefc7 <+855>: mov %esi,%eax 0xf5aaefc9 <+857>: pop %esi 0xf5aaefca <+858>: pop %edi 0xf5aaefcb <+859>: pop %ebp 0xf5aaefcc <+860>: ret => 0xf5aaefcd <+861>: movdqa %xmm0,0x10(%esp) 0xf5aaefd3 <+867>: call 0xf5a01570 <__m128i_strloadu.constprop.1> 0xf5aaefd8 <+872>: movdqa 0x10(%esp),%xmm2 0xf5aaefde <+878>: movdqa %xmm0,(%esp) 0xf5aaefe3 <+883>: jmp 0xf5aaecd0 <__strstr_sse42+96> 0xf5aaefe8 <+888>: mov 0x44(%esp),%edi 0xf5aaefec <+892>: cmpb $0x0,0x1(%edi) 0xf5aaeff0 <+896>: jne 0xf5aaeffe <__strstr_sse42+910> 0xf5aaeff2 <+898>: cmp %al,%dl 0xf5aaeff4 <+900>: mov 0x40(%esp),%esi 0xf5aaeff8 <+904>: je 0xf5aaed1d <__strstr_sse42+173> 0xf5aaeffe <+910>: xor %esi,%esi 0xf5aaf000 <+912>: add $0x30,%esp 0xf5aaf003 <+915>: mov %esi,%eax 0xf5aaf005 <+917>: pop %esi 0xf5aaf006 <+918>: pop %edi 0xf5aaf007 <+919>: pop %ebp 0xf5aaf008 <+920>: ret 0xf5aaf009 <+921>: mov %ebp,%edx 0xf5aaf00b <+923>: mov %esi,0x40(%esp) 0xf5aaf00f <+927>: test %edx,%edx 0xf5aaf011 <+929>: jne 0xf5aaef8c <__strstr_sse42+796> 0xf5aaf017 <+935>: xor %esi,%esi 0xf5aaf019 <+937>: jmp 0xf5aaf000 <__strstr_sse42+912> End of assembler dump. (gdb)
Bug Wranglers - Please re-open. This is a valid and non-dupe bug for x86 and x86-64. It has nothing to do with the original close reason (Steam).
I'll let them have a second look, although acroread is still proprietary and you might want to bug the relevant upstream(s) for that; is there anything else non-proprietary that you can reproduce this with?
Source: https://sourceware.org/glibc/wiki/Release/2.18 "5.3.2. Issues with ``__strstr_sse42`` It has been reported that after upgrading to 2.18 some users have experienced crashes in __strstr_sse42. The first reports of this were from Allan McRae (Arch Linux) here: http://www.sourceware.org/ml/libc-alpha/2013-08/msg00257.html. It appears that this is a compiler issue, but none the less it results in a non-functioning glibc 2.18 that passes the testsuite cleanly but then causes most of x86 userspace to crash. The fundamental issue is that the psABI is not followed and the stack is not maintained aligned. If __strstr_sse42 is called with an unaligned stack it will fault as this violates the psABI. The only real solution is to patch glibc to make these functions inline again, but that isn't a real fix and only papers over the actual problem which will eventually occur if any of the code is perturbed enough to get a misaligned stack again. At present there are two potential solutions. The first solution is to disable the use of the SSE42 routines in glibc, but that has a performance penalty. The consensus around a correct solution is to rebuild the faulty code that calls __strstr_sse42 with a new enough compiler (any gcc released after the year 2000 when -msse went in with the 16 byte stack alignment) that always ensures the stack is aligned modulo 16 bytes, or to correct any assembly that may leave the stack unaligned. There is still some debate over the issue since glibc should try to be as backwards compatible as possible and should therefore support older binaries with misaligned stacks calling SSE42 strstr, and doing this would require new entry points that do dynamic stack realingment. However, doing the dynamic stack realignment is an added cost to the SSE42 strstr routine which already has poor asymptotic performance whom several argue should be removed entirely or fixed, see bug https://sourceware.org/bugzilla/show_bug.cgi?id=12100." See also upstream commit: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=584b18eb4df61ccd447db2dfe8c8a7901f8c8598 As we can see from the acroread stack trace in Comment 3, the stack is clearly not aligned to 16. I'll investigate further what triggered the unaligned stack and post details in a day or so.
right, i don't see this being a bug in glibc should be easy to write a simple shared lib that does like: char *strstr(const char *haystack, const char *needle) { size_t hlen = strlen(haystack); size_t nlen = strlen(needle); return memmem(haystack, needle, hlen, nlen); } then LD_PRELOAD it to keep the app from crashing
I guess glibc 2.19 won't have this problem, per this recent commit: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=584b18eb4df61ccd447db2dfe8c8a7901f8c8598;hp=8a5c7897dd1c52ca74b06aaf5a3bacf0919c97aa After looking into it a little more, I think its safe to point the finger at acroread. Adobe should fix their stack.
For glibc-2.17 is see Program received signal SIGSEGV, Segmentation fault. 0x572c9b78 in __strcasestr_sse42_nonascii () from /lib32/libc.so.6 Don't know whether this is directly related to this bug.
Running glibc-2.18-r1 and acroread-9.5.5 here, and it's all good. Just saying. Denis.
(In reply to Denis Dupeyron from comment #10) > Running glibc-2.18-r1 and acroread-9.5.5 here, and it's all good. Just > saying. I also don't have any problems on my old laptop with Core2Duo CPU, which doesn't have SSE*4* instructions. On my i7 workstation this problem definitely occurs, and can be cured with the LD_PRELOAD hack (after I made the code compile - the arguments are in wrong order). That being said, I'd still like to ask for inclusion of the official upstream fix to allow unaligned arguments.
(In reply to Holger Hoffstätte from comment #11) what upstream fix ? glibc hasn't made any changes, nor do i plan on adding anything to glibc to workaround a bug in old/broken binary packages.
(In reply to SpanKY from comment #12) > (In reply to Holger Hoffstätte from comment #11) > > what upstream fix ? The changes for glibc 2.19 mentioned in comment #8 seem easy to backport. I gave it a try and the only conflict was in the Makefile. > glibc hasn't made any changes, nor do i plan on adding > anything to glibc to workaround a bug in old/broken binary packages. I understand that binaries can be broken (esp. Acroread has some other laughable problems, like containing half an embedded old zlib), but that doesn't really help anyone who needs an application. Expecting Adobe to fix their build is unrealistic. If this were Skype or Firefox people would effectively be forced to abandon Gentoo or fiddle with the LD_PRELOAD hack - not realistic for most people. glibc in Gentoo routinely contains fixes and backports (thanks!), so I'm not sure why this would be different, esp. since it would only be temporary. All that being said, I'm not a Gentoo or glibc committer. I can gladly provide the one-liner fix I made for getting Acroread up and running with the preload hack so that we can fix the problem locally in an acroread-bin revbump. Would this be more acceptable?
(In reply to Holger Hoffstätte from comment #13) glibc-2.19 is going to be out shortly, so people can test it then. i don't plan on backporting those changes at this time to glibc-2.18. as for binary compatibility, honestly i don't care as i have no sympathy for them. maybe the adobe maintainers might consider inlining the LD_PRELOAD hack in their package to mitigate. if the issue only manifests itself with glibc 2.18, then perhaps we'll just ignore the problem until 2.18 comes & goes through the tree. re-Firefox, i don't know what you mean. it's an open source project that is kept up to date and doesn't have this problem. or people could simply build it themselves from source. re-Skype, i still have no sympathy for that project either.
I'd like to add that my natively compiled wine crashes with 2.18 as well. Also, there's nothing to fix on the application side. Demanding higher than 32bit/4byte alignment is not part of the x86 ABI, so aligned SIMD loads from passed parameters violate the ABI.
*** Bug 500250 has been marked as a duplicate of this bug. ***
glibc-2.18 has just broken nearly all my x86 system (including python, X.org and gdb/gcc), I am not sure it should be ~x86.
Reports on IRC show that glibc-2.18 is breaking ~x86 systems right and left. Maybe someone should mask it?
Broken in glibc-2.18-r1, upgrading to glibc-2.19 fixed this for me.
sys-libs/glibc-2.19 fixed for me
Perhaps one of the two above could post just how they installed glibc-2.19. Thanks.
Created attachment 370190 [details] emerge --info Yes, I know... git kernel
Sorry-- sys did not add comments... unmask glibc-2.19 build && install # env-update && source /etc/profile # revdep-rebuild 'just some firefox things' yay! works as designed :)
It seems that the step "unmask glibc-2.19" is excaping me. Just putting it in /etc/portage/package.unmask does not do it for me.
(In reply to Fred Krogh from comment #24) > It seems that the step "unmask glibc-2.19" is excaping me. Just putting it > in /etc/portage/package.unmask does not do it for me. # echo "=sys-libs/glibc-2.19 **" >> /etc/portage/package.keywords
*** Bug 500812 has been marked as a duplicate of this bug. ***
@printing, would you mind adding an LD_PRELOAD hack until 2.19 is unmasked? acroread is kinda a critical package for some people - open-source pdf viewers are great for *viewing* pdfs, but not for filling out pdf forms...
glibc-2.19 is in ~arch now