Created attachment 501388 [details] app-office:libreoffice-5.4.2.2:20171031-092715.log.gz Emerging libreoffice fails for me with a SIGSEGV running /usr/sbin/gencmn from dev-libs/icu-58.2-r1: S=/var/tmp/portage/app-office/libreoffice-5.4.2.2/work/libreoffice-5.4.2.2 && I=$S/instdir && W=$S/workdir && RESPONSEFILE=/var/tmp/portage/app-office/libreoffice-5.4.2.2/temp/gbuild.I60Kq0 && echo 'char_in.brk' >> ${RESPONSEFILE} && echo 'char.brk' >> ${RESPONSEFILE} && echo 'count_word.brk' >> ${RESPONSEFILE} && echo 'dict_word_he.brk' >> ${RESPONSEFILE} && echo 'dict_word_hu.brk' >> ${RESPONSEFILE} && echo 'dict_word_nodash.brk' >> ${RESPONSEFILE} && echo 'dict_word_prepostdash.brk' >> ${RESPONSEFILE} && echo 'dict_word.brk' >> ${RESPONSEFILE} && echo 'edit_word_he.brk' >> ${RESPONSEFILE} && echo 'edit_word_hu.brk' >> ${RESPONSEFILE} && echo 'edit_word.brk' >> ${RESPONSEFILE} && echo 'line.brk' >> ${RESPONSEFILE} && echo 'sent.brk' >> ${RESPONSEFILE} && /usr/sbin/gencmn -n OpenOffice -t tmp -S -d $W/CustomTarget/i18npool/breakiterator/ 0 ${RESPONSEFILE} && rm -f ${RESPONSEFILE} && echo '#ifdef _MSC_VER' > $W/CustomTarget/i18npool/breakiterator/OpenOffice_dat.c && echo '#pragma warning( disable : 4229 4668 )' >> $W/CustomTarget/i18npool/breakiterator/OpenOffice_dat.c && echo '#endif' >> $W/CustomTarget/i18npool/breakiterator/OpenOffice_dat.c && cat $W/CustomTarget/i18npool/breakiterator/OpenOffice_tmp.c >> $W/CustomTarget/i18npool/breakiterator/OpenOffice_dat.c /bin/sh: line 1: 9776 Segmentation fault /usr/sbin/gencmn -n OpenOffice -t tmp -S -d $W/CustomTarget/i18npool/breakiterator/ 0 ${RESPONSEFILE} Re-tried the emerge with the same result, so this appears to be somewhat reproducible. On the other hand, running the command all by itself seems to work just fine. Could this have something to do with sandboxing?
I have the same problem with gcc-7.2.0
I edited $S/i18npool/CustomTarget_breakiterator.mk and included a “ulimit -c unlimited” in there to obtain a core dump. From that I got a backtrace: #0 in sb_check_exec (filename=filename@entry "/usr/sbin/gencmn", argv=argv@entry) at /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/wrapper-funcs/__wrapper_exec.c:192 #1 in execve_DEFAULT (path=path@entry "/usr/sbin/gencmn", argv=argv@entry, envp=envp@entry) at /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/wrapper-funcs/__wrapper_exec.c:273 #2 in shell_execve (command=command@entry "/usr/sbin/gencmn", args, env at execute_cmd.c:5457 #3 in execute_disk_command (cmdflags=<optimized out>, fds_to_close, async=0, pipe_out=-1, pipe_in=-1, command_line "/usr/sbin/gencmn -n OpenOffice -t tmp -S -d $W/CustomTarget/i18npool/breakiterator/ 0 ${RESPONSEFILE}", redirects=0x0, words) at execute_cmd.c:5251 (I stripped addresses from this.) So this does look like a sandbox issue. The source location is of limited value, as it refers to the line were a HUGE macro called PARSE_ELF is instantiated. But at least this gives a better way to reproduce the issue: $ sandbox /usr/sbin/gencmn --help Sandboxed process killed by signal: Segmentation fault Segmentation fault Manually expanding the PARSE_ELF(64) macro instantiation, I get the error down to this check: symname[0] == '_' && symname[1] == '_' It seems symname[0] is out of range, unmapped. As the comment above that code talks about prelink, I should point out that I am using prelink on my system. vhash=0 and vliblist!=0 on my system. (gdb) p ((void *)symend - (void *)(elf + symoff)) $18 = 3904 (gdb) p sizeof(Elf64_Sym) $19 = 24 But 3904 is not a multiple of 24, which I would consider an indication of a possible problem. readelf has this to say about the binary in question: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .interp PROGBITS 0000000000400238 00000238 000000000000001c 0000000000000000 A 0 0 1 [ 2] .note.ABI-tag NOTE 0000000000400254 00000254 0000000000000020 0000000000000000 A 0 0 4 [ 3] .gnu.hash GNU_HASH 0000000000400278 00000278 0000000000000040 0000000000000000 A 4 0 8 [ 4] .dynsym DYNSYM 00000000004002b8 000002b8 0000000000000150 0000000000000018 A 16 1 8 [ 5] .gnu.version VERSYM 00000000004004c4 000004c4 000000000000001c 0000000000000002 A 4 0 2 [ 6] .gnu.version_r VERNEED 00000000004004e0 000004e0 0000000000000030 0000000000000000 A 16 1 8 [ 7] .rela.dyn RELA 0000000000400510 00000510 0000000000000060 0000000000000018 A 4 0 8 [ 8] .rela.plt RELA 0000000000400570 00000570 0000000000000060 0000000000000018 AI 4 23 8 [ 9] .init PROGBITS 00000000004005d0 000005d0 0000000000000017 0000000000000000 AX 0 0 4 [10] .plt PROGBITS 00000000004005f0 000005f0 0000000000000050 0000000000000010 AX 0 0 16 [11] .text PROGBITS 0000000000400640 00000640 00000000000003a2 0000000000000000 AX 0 0 32 [12] .fini PROGBITS 00000000004009e4 000009e4 0000000000000009 0000000000000000 AX 0 0 4 [13] .rodata PROGBITS 00000000004009f0 000009f0 0000000000000555 0000000000000000 A 0 0 8 [14] .eh_frame_hdr PROGBITS 0000000000400f48 00000f48 0000000000000034 0000000000000000 A 0 0 4 [15] .eh_frame PROGBITS 0000000000400f80 00000f80 000000000000012c 0000000000000000 A 0 0 8 [16] .dynstr STRTAB 00000000004010ac 000010ac 000000000000014b 0000000000000000 A 0 0 1 [17] .gnu.liblist GNU_LIBLIST 00000000004011f8 000011f8 00000000000000dc 0000000000000014 A 16 0 4 Reading some more of the libsandbox source code comment: /* Nowhere is the # of symbols recorded, or the size of the symbol * table. Not sure why the size of the relevant sections isn't clue enough here. Can't we just walk all of the dynsym section and be dome with it? I mean walk till the beginning of the next section, without relying on what section that would be. * Instead, we do what glibc does: use the sysv hash table * if it exists, else assume that the string table always directly * follows the symbol table. The above binary appears to violate this assumption. * This seems like a poor assumption to * make, but glibc has gotten by this long. See determine_info in * glibc's elf/dl-addr.c. Yes, there is indeed some code in there that looks similar. * * Turns out prelink will violate that assumption. Fortunately it * will insert its liblist at the same location all the time -- it * replaces the string table with its liblist table. Didn't do that in the above example. * * Long term, we should behave the same as glibc and walk the gnu * hash table first before falling back to the raw symbol table. This MIGHT be the proper solution here. * * We don't sanity check the ranges here as you aren't executing * corrupt programs in the sandbox. */ Not corrupt, but not following all the hand-wavey assumptions here either. Which makes debugging extra hard.
Created attachment 506792 [details] /usr/sbin/gencmn The gencmn binary from my system, in the hope that this helps to better understand the ELF layout in this specific case.
Workaround: prelink -u /usr/sbin/gencmn && emerge -1 libreoffice
Martin, The prelink workaround works for me, thank you
*** This bug has been marked as a duplicate of bug 599894 ***
*** Bug 647542 has been marked as a duplicate of this bug. ***
FYI: With icu-60.2 libreoffice-6.0.1.1 builds fine.
