On Wed, 06 Sep 2017 00:11:28 -0700 James Richard Tyrer <[email protected]> wrote:
> [ ~ ]# cat /tmp/acroCrashLogs/0906_0001_wJDhzR > /usr/bin/acroread [0x850ab41] [@0x8048000] > linux-gate.so.1(__kernel_sigreturn+0x0) [0xffffe400] [@0xffffe000] > > This doesn't look like much information to me. James, Yeah, but what there is of it looks just like that glibc-2.18 problem you mentioned: https://bugs.gentoo.org/show_bug.cgi?id=488918 and there is a known stack alignment issue with the acroread binary that can only be removed by recompiling acroread with a newer compiler. Perhaps the issue is back once again with the most recent versions of glibc? From the link above, can you also produce a gdb backtrace like the one on comment #3? One test you can do is to install a (temporary) test version of your current version of glibc, but one with SSE instructions turned off. Check the glibc configure options, and/or set your CFLAGS when compiling glibc to: -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 and see if your special version of glibc allows acroread to work. Also, invoking full optimization ( -O3 ) might overcome the problem as well (because doing so inlines the functions that would cause a stack crash): http://www.sourceware.org/ml/libc-alpha/2013-08/msg00257.html You can also create a special (or older, what you were using before the upgrade) version of glibc and then use LD_PRELOAD to preload that library for acroread. You can also do the LD_PRELOAD trick with just the specific function as mentioned in comment 7 in the gentoo link above (if that function is the only thing that trips acroread). However, beware: do not allow any older version of glibc to install its headers into your (include) system, better to just copy its libc-X.so manually to a special place or with a special name in /lib. Cheers, Mike -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
