=app-text/acroread-9.5.5-r3 fails with "Cannot access memory ..." This maybe occurring due to some depend libraries being compiled with Program received signal SIGSEGV, Segmentation fault. _______________________________________________________________________________ eax:09EA5030 ebx:413A7000 ecx:50069420 edx:FFFFA95C eflags:00010292 esi:000103E4 edi:A54FF53A esp:FFFFA8EC ebp:09EA5030 eip:41375C40 cs:0023 ds:002B es:002B fs:0000 gs:0063 ss:002B o d I t S z A p c [002B:FFFFA8EC]---------------------------------------------------------[stack] FFFFA91C : 69 5E EB 4F CC DF EC 4F - 70 B4 26 41 C0 82 15 F6 i^.O...Op.&A.... FFFFA90C : 69 5E EB 4F E7 DA 35 41 - A3 E4 35 41 6C 42 C2 F6 i^.O..5A..5AlB.. FFFFA8FC : 01 00 00 00 00 00 00 00 - 01 00 00 00 C0 82 15 F6 ................ FFFFA8EC : 54 A9 FF FF CE 5E EB 4F - 49 E5 26 41 E7 DA 35 41 T....^.OI.&A..5A [002B:A54FF53A]---------------------------------------------------------[ data] A54FF53A : Error while running hook_stop: Cannot access memory at address 0xa54ff53a 0x41375c40 in FcHashComputeSHA256Digest () from /usr/lib32/libfontconfig.so.1 gdb> bt #0 0x41375c40 in FcHashComputeSHA256Digest () from /usr/lib32/libfontconfig.so.1 #1 0x413767ad in FcHashGetSHA256DigestFromMemory () from /usr/lib32/libfontconfig.so.1 #2 0x41374fad in FcFreeTypeQueryFace () from /usr/lib32/libfontconfig.so.1 #3 0x413750b4 in FcFreeTypeQuery () from /usr/lib32/libfontconfig.so.1 #4 0x4136f94f in FcFileScanConfig () from /usr/lib32/libfontconfig.so.1 #5 0x4136fccd in FcDirScanConfig () from /usr/lib32/libfontconfig.so.1 #6 0x4136fe13 in FcDirCacheScan () from /usr/lib32/libfontconfig.so.1 #7 0x413644d3 in FcConfigBuildFonts () from /usr/lib32/libfontconfig.so.1 #8 0x41377208 in FcInitLoadConfigAndFonts () from /usr/lib32/libfontconfig.so.1 #9 0x41367996 in FcConfigSubstituteWithPat () from /usr/lib32/libfontconfig.so.1 #10 0x41368277 in FcConfigSubstitute () from /usr/lib32/libfontconfig.so.1 #11 0x43eed8d1 in pango_cairo_fc_font_map_fontset_key_substitute () from /usr/lib32/libpangocairo-1.0.so.0 #12 0x413b2395 in pango_fc_font_map_load_fontset () from /usr/lib32/libpangoft2-1.0.so.0 #13 0x414a3a37 in pango_font_map_load_fontset () from /usr/lib32/libpango-1.0.so.0 #14 0x4149fd59 in itemize_state_process_run () from /usr/lib32/libpango-1.0.so.0 #15 0x414a1497 in pango_itemize_with_base_dir () from /usr/lib32/libpango-1.0.so.0 #16 0x414916b7 in pango_layout_check_lines.part () from /usr/lib32/libpango-1.0.so.0 #17 0x414ab03f in pango_layout_get_unknown_glyphs_count () from /usr/lib32/libpango-1.0.so.0 #18 0x4409cc38 in find_invisible_char () from /usr/lib32/libgtk-x11-2.0.so.0 #19 0x440a0723 in gtk_entry_init () from /usr/lib32/libgtk-x11-2.0.so.0 #20 0x41032bb3 in g_type_create_instance () from /usr/lib32/libgobject-2.0.so.0 #21 0x410153ca in g_object_newv () from /usr/lib32/libgobject-2.0.so.0 #22 0x41016108 in g_object_new () from /usr/lib32/libgobject-2.0.so.0 #23 0x440a2504 in gtk_entry_new () from /usr/lib32/libgtk-x11-2.0.so.0 #24 0x08555a90 in _start () Reproducible: Always
Think I just solved this by recompiling media-libs/fontconfig using debug flags. acroread precompiled binary seems to be gaining a temper when using certain CFLAGS with it's depends. I have had very few, if any problems with any other source (or even binary) executables for many years until just recently. And only with acroread, for which I've used off and on for the past many years. It maybe 32bit applications (when compiled on 64 bit platforms using ABI USE flag variable) cannot handle vectorization CFLAGS, or other than basic or even debug CFLAGS.
I've further narrowed this to acroread only being able to utilize fontconfig when absolutely using debug flags only! CFLAGS="-g -Wall -ggdb" Trying any other CFLAG seems to always create the following backtrace.
I'm wondering at this point if we can specify the ABI_x86 when adding package names to the "/etc/portage/package.env" file. Further specifying the ABI will allow ABI_x86=32 bit packages to be compiled using alternate CFLAGS from the system CFLAGS, and the ABI_x86=64 bit package to also be compiled using the default system CFLAGS. It maybe this problem is extremely localized to either acroread or 32 bit applications when compiled on 64 bit platforms?
Forget the mention of fontconfig not being usable by acroread with any CFLAGS except debug CFLAGS. I have localized this bug to fontconfig being compiled with vectorization CFLAGS. This can be averted by using CFLAGS="-march=corei7 -Ofast -pipe -fno-tree-slp-vectorize" within /etc/portage/package.env file. However, I'm still curious as to whether this is an issue localized to only 32 bit precompiled acroread binary, as I've seen similar with pango and cairo packages. And yet, I've never seen any segmentation faults with any other packages for many years using my same system CFLAGS, until very recently when starting to use ABI 32 bit or these later versions of acroread. (ie. See also Bug #559258 - x11-libs/cairo and x11-libs/pango with -O3 & -Ofast cause acroread segmentation fault within /usr/lib32/libpangocairo-1.0.so.0)
Hello Roger, do you consider this done or would you like some more investigation from the team?
I would just suggest monitoring the bug or issue here. If this bug interests you, I would suggest referencing Bug #559258 "x11-libs/cairo and x11-libs/pango with -O3 & -Ofast cause acroread segmentation fault ..." Deploying gdb on acroread is a hassle, as using gdb with the "/opt/Adobe/Reader9/bin/acroread" script file requires prefixing the last two $ACRO_EXEC_CMD variables (near end of the file) with gdb and then manually executing this file from it's static location. Difficult for most users, but some may understand this and find this bug and the other. From here, I'll likely have to hand the reigns over to Holger Hoffstätte, as it sounds he may have a better idea what's going on. (Looks to be targeted towards the current multilib 32 bit method and precompiled 32 bit binaries?)
Just recently, even after recompiling fontconfig using debug CFLAGS, now still getting a segfault. Program received signal SIGSEGV, Segmentation fault. _______________________________________________________________________________ eax:09EBAAD8 ebx:F6156000 ecx:00000000 edx:09EBAAC4 eflags:00010246 esi:24E53AF3 edi:00000000 esp:FFFFAF2C ebp:09EBAAC0 eip:F6125717 cs:0023 ds:002B es:002B fs:0000 gs:0063 ss:002B o d I t s Z a P c [002B:FFFFAF2C]---------------------------------------------------------[stack] FFFFAF5C : 00 90 A3 BF 4F 3F 7F 42 - 10 B5 EB 09 76 05 C3 2A ....O?.B....v..* FFFFAF4C : 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................ FFFFAF3C : F8 60 A0 F3 00 00 F0 3F - 03 00 00 00 20 61 A0 F3 .`.....?.... a.. FFFFAF2C : 04 00 00 00 00 00 00 00 - 00 00 00 00 1A 00 00 00 ................ [002B:24E53AF3]---------------------------------------------------------[ data] 24E53AF3 : Error while running hook_stop: Cannot access memory at address 0x24e53af3 0xf6125717 in FcPatternHash () from /usr/lib32/libfontconfig.so.1 gdb> bt #0 0xf6125717 in FcPatternHash () from /usr/lib32/libfontconfig.so.1 #1 0x4fa1f703 in g_hash_table_lookup () from /usr/lib32/libglib-2.0.so.0 #2 0x436c132f in pango_fc_fontset_get_font_at () from /usr/lib32/libpangoft2-1.0.so.0 #3 0x436c1929 in pango_fc_fontset_foreach () from /usr/lib32/libpangoft2-1.0.so.0 #4 0x4fcb31f6 in pango_fontset_foreach () from /usr/lib32/libpango-1.0.so.0
From http://unix.stackexchange.com/questions/3505/how-to-install-adobe-acrobat-reader-in-debian --- Begin of Snip --- NOTE: The 9.x branch of reader has been EOL'd as of June 26, 2013. If you need native Adobe Reader support on Linux, 9.x is your only option! 10 doesn't list Linux as being supported, and likely never will. More on it too here: Adobe abandons Linux. (http://www.zdnet.com/blog/open-source/adobe-abandons-linux/10418) --- End of Snip --- Fontconfig, pango and cairo haven't been updated in a while, and yet something else is spawning the break within fontconfig from outside those three libraries. Looks like I have to give up on this acroread bug, but I do use evince/mupdf most times.
*** This bug has been marked as a duplicate of bug 559258 ***
