The symptom is adobe reader not starting. strace reveals a segfault: --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- rt_sigaction(SIGABRT, {SIG_DFL, [ABRT], SA_RESTART}, {0x850aafa, [], 0}, 8) = 0 exit_group(1) ltrace reveals the segfault position outside adobe reader itself: 22620 gtk_menu_item_new_with_label(0x8c7389e, 0x5000023, 0, 0xa1e50c8 <no return ...> 22620 --- SIGSEGV (Segmentation fault) --- gdb tells more: Program received signal SIGSEGV, Segmentation fault. 0xf6693724 in ?? () from /usr/lib32/libgobject-2.0.so.0 (gdb) bt #0 0xf6693724 in ?? () from /usr/lib32/libgobject-2.0.so.0 #1 0xf66970fc in g_type_add_interface_static () from /usr/lib32/libgobject-2.0.so.0 [further irrelevant parts clipped without comment from here on] disassembly of the function before the unnamed: 0xf66970e6 <+230>: je 0xf6697150 <g_type_add_interface_static+336> 0xf66970e8 <+232>: mov 0x58(%esp),%esi 0xf66970ec <+236>: movl $0x0,0x4(%esp) 0xf66970f4 <+244>: mov %esi,(%esp) 0xf66970f7 <+247>: call 0xf66932c0 0xf66970fc <+252>: mov %ebp,(%esp) 0xf66970ff <+255>: call 0xf666caf0 <g_rw_lock_writer_unlock@plt> I am pretty sure from this that the unnamed function is static void type_add_interface_Wm in glib-2.36.4/gobject/gtype.c, lines 1463ff. disassembly of the crashing function: [...] 0xf6693719: add $0x1,%edi 0xf669371c: mov %edi,0x68(%esp) 0xf6693720: mov 0x50(%esp),%edx => 0xf6693724: movdqa %xmm0,0x20(%esp) 0xf669372a: movl $0x0,0x4(%esp) 0xf6693732: add $0x1,%edx [...] The program segfaults on a movqda instructions. Since this is a CPU with SSE up to 4.1 support, this is not an illegal instructions, which means that either the operand is unaligned, or the SSE state is invalid. In my case I can see that the stack pointer is not 16byte aligned as the instruction expects. I'll assume that acroread is compiled with a lower stack alignment. I would like to propose to compile the libraries with a lower stack alignment, forcing gcc to align the stack itself, or to compile them without SSE support (which would possibly slow down things, but increase compatibility).
Note: Bug might be hard to reproduce, I have it on one of my two gentoo systems only (it appears on a Core2Duo, but not on a Haswell).
If it's the 32bit glib in emul-linux-x86- causing the crash, then this is likely solved by ABI_X86="32" in dev-libs/glib in ~arch already As in, the emul-linux-x86-* is deprecated in favour of the new way of building multilib and won't be upgraded anymore [ebuild R ] dev-libs/glib-2.36.4-r1:2 USE="-debug (-fam) (-selinux) -static-libs -systemtap {-test} -utils -xattr" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 -python2_6" 8,303 kB $ qfile -b -v /usr/lib32/libglib-2.0.so dev-libs/glib-2.36.4-r1 (/usr/lib64/libglib-2.0.so) dev-libs/glib-2.36.4-r1 (/usr/lib32/libglib-2.0.so)
emul sets were compiled with 4.7.3-r1 with -O2 -mtune=i686 -pipe (as has been always the case) Also, I cannot reproduce any acroread crash :/
Thank you. Sadly, your suggestion didn't quite work as well. However, to document the solution here, I had to change my make.conf and recompile both fontconfig and glib with these settings: CFLAGS="-O3 -pipe" CFLAGS_amd64="-m64 -mtune=core2 -mfpmath=sse" CFLAGS_x86="-m32 -mtune=i686" The ricer config -mfpmath=sse added SSE instructions to normal code that could lead to unaligned access violations from binaries not compiled with it, such as precompiled third party blobs (acroread, in my case).
