Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 488918 - app-text/acroread crashes with =sys-libs/glibc-2.18 (segfaults in __strstr_sse42 () from /lib32/libc.so.6)
Summary: app-text/acroread crashes with =sys-libs/glibc-2.18 (segfaults in __strstr_ss...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Printing Team
URL: https://bugs.archlinux.org/task/36556
Whiteboard:
Keywords:
: 500250 500812 (view as bug list)
Depends on:
Blocks: glibc-2.18
  Show dependency tree
 
Reported: 2013-10-21 17:51 UTC by Dmitry Derevyanko
Modified: 2014-03-29 17:01 UTC (History)
20 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
revert a part of commit (strstr.patch,1.09 KB, patch)
2013-10-21 17:52 UTC, Dmitry Derevyanko
Details | Diff
emerge --info (emerge_info.txt,5.33 KB, text/plain)
2014-02-12 00:23 UTC, Scott Short
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Derevyanko 2013-10-21 17:51:27 UTC
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
Comment 1 Dmitry Derevyanko 2013-10-21 17:52:27 UTC
Created attachment 361552 [details, diff]
revert a part of commit

This patch works for me.
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-22 13:07:57 UTC
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 ***
Comment 3 befros 2014-01-02 06:54:15 UTC
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)
Comment 4 befros 2014-01-03 16:46:46 UTC
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).
Comment 5 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-01-03 17:03:05 UTC
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?
Comment 6 befros 2014-01-03 18:39:24 UTC
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.
Comment 7 SpanKY gentoo-dev 2014-01-03 19:29:50 UTC
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
Comment 8 befros 2014-01-04 08:00:53 UTC
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.
Comment 9 Justin Lecher (RETIRED) gentoo-dev 2014-01-20 08:17:31 UTC
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.
Comment 10 Denis Dupeyron (RETIRED) gentoo-dev 2014-01-30 19:56:26 UTC
Running glibc-2.18-r1 and acroread-9.5.5 here, and it's all good. Just saying.

Denis.
Comment 11 Holger Hoffstätte 2014-01-31 08:37:09 UTC
(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.
Comment 12 SpanKY gentoo-dev 2014-01-31 21:09:37 UTC
(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.
Comment 13 Holger Hoffstätte 2014-01-31 23:42:58 UTC
(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?
Comment 14 SpanKY gentoo-dev 2014-02-01 05:08:18 UTC
(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.
Comment 15 Christian Schmidt 2014-02-04 15:36:30 UTC
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.
Comment 16 SpanKY gentoo-dev 2014-02-04 17:57:06 UTC
*** Bug 500250 has been marked as a duplicate of this bug. ***
Comment 17 Dmitry Dzhus 2014-02-07 14:28:08 UTC
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.
Comment 18 Christian Schmidt 2014-02-09 10:15:42 UTC
Reports on IRC show that glibc-2.18 is breaking ~x86 systems right and left. Maybe someone should mask it?
Comment 19 Andrew Waters 2014-02-10 07:59:40 UTC
Broken in glibc-2.18-r1, upgrading to glibc-2.19 fixed this for me.
Comment 20 MZ 2014-02-11 18:55:23 UTC
sys-libs/glibc-2.19 fixed for me
Comment 21 Fred Krogh 2014-02-12 00:03:43 UTC
Perhaps one of the two above could post just how they installed glibc-2.19.  Thanks.
Comment 22 Scott Short 2014-02-12 00:23:33 UTC
Created attachment 370190 [details]
emerge --info

Yes, I know... git kernel
Comment 23 Scott Short 2014-02-12 00:28:47 UTC
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 :)
Comment 24 Fred Krogh 2014-02-12 00:38:07 UTC
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.
Comment 25 Scott Short 2014-02-12 00:48:44 UTC
(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
Comment 26 SpanKY gentoo-dev 2014-02-16 02:55:46 UTC
*** Bug 500812 has been marked as a duplicate of this bug. ***
Comment 27 Alexandre Rostovtsev (RETIRED) gentoo-dev 2014-03-04 15:49:20 UTC
@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...
Comment 28 SpanKY gentoo-dev 2014-03-29 17:01:44 UTC
glibc-2.19 is in ~arch now