Summary: | www-client/chromium-63.0.3239.84: FAILED: gen/blink/platform/CharacterPropertyData.cpp | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | wbrana |
Component: | Current packages | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | chromium, h.mth, mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
build log with usersandbox readelf -a character_data_generator sandbox: crashfix bogus symbol table looping sandbox: crashfix looping bogus symbol table sandbox: crashfix no valid symbol name |
Description
wbrana
2017-12-07 15:05:27 UTC
should I post also those outputs and build log? Hmm.. I'm not sure if the python segfault is related. The log seems to indicate that the character_data_generator program is exiting with status -11, which seems to indicate a segfault in that program. Perhaps PaX is killing it? kernel log contain following errors after build failure: [kernel] python2.7[30398]: segfault at 37a6ef78899 ip 0000037a655f2a98 sp 0000039abd1514a0 error 4 in libsandbox.so[37a655ea000+17000] [kernel] grsec: Segmentation fault occurred at 0000037a6ef78899 in /usr/bin/python2.7[python2.7:30398] uid/euid:250/250 gid/egid:250/250, parent /usr/bin/python2.7[python2.7:30397] uid/euid:250/250 gid/egid:250/250 [kernel] grsec: bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds. Please investigate the crash report for /usr/bin/python2.7[python2.7:30398] uid/euid:250/250 gid/egid:250/250, parent /usr/bin/python2.7[python2.7:30397] uid/euid:250/25 0 gid/egid:250/250 there are also following errors when I run /usr/bin/paxtest PAX: execution attempt in PAX: terminating task grsec: denied RWX mprotect of there is core dump from python, but can't get proper backtrace even if python and libsandbox.so are compiled with debugging symbols tried to run from command line and there is no crash cd /tmp/portage/www-client/chromium-63.0.3239.84/work/chromium-63.0.3239.84/out/Release/ sudo -u portage /usr/bin/python2.7 ../../third_party/WebKit/Source/build/scripts/gperf.py /tmp/portage/www-client/chromium-63.0.3239.84/work/chromium-63.0.3239.84/out/Release/character_data_generator gen/blink/platform/CharacterPropertyData.cpp FEATURES with -usersandbox fixed this error Maybe try upgrading to sandbox-2.12? Also, please upload a full build log and emerge --info. Created attachment 509266 [details]
emerge --info
current info without usersandbox
sandbox-2.12 was already installed
Yeah, then I'm at a loss on this one. Copying sandbox in case someone has any idea here. can't add build log: This site can’t be reached (In reply to wbrana from comment #10) > can't add build log: This site can’t be reached Make sure you compress it first (xz build.log). Created attachment 509270 [details]
build log with usersandbox
build log upload problem was probably caused by wrong file permissions build successful without usersandbox still error with grsec 4.9.68, usersandbox and www-client/chromium-63.0.3239.84::gentoo I got it debugged; libsandbox crashes in 'sb_check_exec'[0] parsing 64 bit elf structure of 'character_data_generator'. I commented out the PARSE_ELF(...) calls and put 'goto done;' to skip 'trace_possible', which slows execution dramatically. Is there any way to see how the elf structure of 'character_data_generator' looks like to see what is missing? With scanelf or objdump? Binutils changed elf structure lately, IIRC? Or is it clang related? I built chromium with gcc before and it happened with chromium 65 and clang, which is forced. Many random ideas. Anyone help sorting out? :-) [0] https://gitweb.gentoo.org/proj/sandbox.git/tree/libsandbox/wrapper-funcs/__wrapper_exec.c?h=v2.13#n189 ___ Build sandbox with debugging symbols. Run 'emerge chromium' until crash or compile stage and Ctrl-C to skip unnecessary build-time of mksnapshot and V8. Then execute following commands in 'out/Release' of chromium build to see crash in gdb: ana Release # runuser -u portage -- ninja character_data_generator [5/5] LINK ./character_data_generator ana Release # runuser -u portage -- sandbox ./character_data_generator gen/blink/platform/CharacterPropertyData.cpp Sandboxed process killed by signal: Segmentation fault Speicherzugriffsfehler ana Release # runuser -u portage -- gdb sandbox GNU gdb (Gentoo 8.1 p1) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from sandbox...Reading symbols from /usr/lib64/debug//usr/bin/sandbox.debug...done. done. (gdb) set args ./character_data_generator gen/blink/platform/CharacterPropertyData.cpp (gdb) set follow-fork-mode child (gdb) r Starting program: /usr/bin/sandbox ./character_data_generator gen/blink/platform/CharacterPropertyData.cpp [New process 2863] process 2863 is executing new program: /bin/bash Thread 2.1 "bash" received signal SIGSEGV, Segmentation fault. [Switching to process 2863] 0x00007ffff7bc2bf8 in sb_check_exec (filename=filename@entry=0x55555583b1d0 "./character_data_generator", argv=argv@entry=0x555555840900) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:192 192 /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x00007ffff7bc2bf8 in sb_check_exec (filename=filename@entry=0x55555583b1d0 "./character_data_generator", argv=argv@entry=0x555555840900) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:192 #1 0x00007ffff7bc48af in execve_DEFAULT (path=0x55555583b1d0 "./character_data_generator", argv=0x555555840900, envp=0x55555583c550) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:273 #2 0x0000555555579d92 in ?? () #3 0x0000555555563252 in ?? () #4 0x000055555557ae28 in ?? () #5 0x00005555555c2a68 in ?? () #6 0x00005555555617e5 in ?? () #7 0x00005555555653ef in ?? () #8 0x00007ffff75c9f0a in __libc_start_main () from /lib64/libc.so.6 #9 0x00005555555660ba in ?? () (gdb) q Created attachment 526162 [details]
readelf -a character_data_generator
JFYI, it looks like libsandbox is parsing the dynamic symbol table, not symbol table. Since I do not want to spam unnecessarily, see on your system output of 'objdump -t character_data_generator' and 'objdump -T character_data_generator'. And to workaround current situation (see comment in source), it needs a break condition added. When 'strcmp(symname, "") == 0 && sym->st_name == 0x20000' (the 131072 below) it is done looping. This means by implication that 'symend' is bogus. Any idea to fix that instead? I added elf32/64 helper functions to be able to debug. See objdump versus gdb session: # objdump -T character_data_generator character_data_generator: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __libc_start_main 0000000000000000 w D *UND* 0000000000000000 Base __gmon_start__ 0000000000000000 w D *UND* 0000000000000000 Base _ITM_deregisterTMCloneTable 0000000000000000 w D *UND* 0000000000000000 Base _ITM_registerTMCloneTable 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 fclose 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 fopen64 0000000000201174 g DF .init 0000000000000000 Base _init 000000000020118c g DF .fini 0000000000000000 Base _fini 00000000002021f8 g D .got.plt 0000000000000000 Base _edata 0000000000203001 g D .bss 0000000000000000 Base _end 0000000000203000 g D .bss 0000000000000000 Base __bss_start (gdb) r Starting program: /usr/bin/sandbox ./character_data_generator gen/blink/platform/CharacterPropertyData.cpp [New process 3017] process 3017 is executing new program: /bin/bash [Switching to process 3017] Thread 2.1 "bash" hit Breakpoint 1, _sb_check_exec_parse_elf64 (st_size=11608, elf=<optimized out>) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:239 239 if ( (gdb) my_cap $1 = {st_name = 72, st_info = 18 '\022', st_other = 0 '\000', st_shndx = 14, st_value = 2101620, st_size = 0} $2 = 0x7ffff7f89480 "_init" Thread 2.1 "bash" hit Breakpoint 1, _sb_check_exec_parse_elf64 (st_size=11608, elf=<optimized out>) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:239 239 if ( (gdb) $3 = {st_name = 78, st_info = 18 '\022', st_other = 0 '\000', st_shndx = 15, st_value = 2101644, st_size = 0} $4 = 0x7ffff7f89486 "_fini" Thread 2.1 "bash" hit Breakpoint 1, _sb_check_exec_parse_elf64 (st_size=11608, elf=<optimized out>) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:239 239 if ( (gdb) $5 = {st_name = 153, st_info = 16 '\020', st_other = 0 '\000', st_shndx = 22, st_value = 2105848, st_size = 0} $6 = 0x7ffff7f894d1 "_edata" Thread 2.1 "bash" hit Breakpoint 1, _sb_check_exec_parse_elf64 (st_size=11608, elf=<optimized out>) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:239 239 if ( (gdb) $7 = {st_name = 160, st_info = 16 '\020', st_other = 0 '\000', st_shndx = 23, st_value = 2109441, st_size = 0} $8 = 0x7ffff7f894d8 "_end" Thread 2.1 "bash" hit Breakpoint 1, _sb_check_exec_parse_elf64 (st_size=11608, elf=<optimized out>) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:239 239 if ( (gdb) $9 = {st_name = 165, st_info = 16 '\020', st_other = 0 '\000', st_shndx = 23, st_value = 2109440, st_size = 0} $10 = 0x7ffff7f894dd "__bss_start" Thread 2.1 "bash" hit Breakpoint 1, _sb_check_exec_parse_elf64 (st_size=11608, elf=<optimized out>) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:239 239 if ( (gdb) $11 = {st_name = 131072, st_info = 1 '\001', st_other = 0 '\000', st_shndx = 1, st_value = 281483566776321, st_size = 281479271743489} $12 = 0x7ffff7fa9438 "" Thread 2.1 "bash" hit Breakpoint 1, _sb_check_exec_parse_elf64 (st_size=11608, elf=<optimized out>) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:239 239 if ( (gdb) my_cap $13 = {st_name = 18923656, st_info = 0 '\000', st_other = 4 '\004', st_shndx = 2368, st_value = 1076797607331758087, st_size = 17065622513011119082} $14 = 0x7ffff91954c0 <error: Cannot access memory at address 0x7ffff91954c0> Thread 2.1 "bash" received signal SIGSEGV, Segmentation fault. _sb_check_exec_parse_elf64 (st_size=11608, elf=<optimized out>) at /mnt/data/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/wrapper-funcs/__wrapper_exec.c:239 239 if ( (gdb) q Created attachment 526176 [details, diff]
sandbox: crashfix bogus symbol table looping
Created attachment 526188 [details, diff]
sandbox: crashfix looping bogus symbol table
Actually testing 'symname' is no good. Do test only for bogus 'sym->st_name'.
I am slowly getting into it. :-) So, looking at glibc source[0] (line 42 and 65), you may better test for 'sym->st_name < str_size' with libsandbox source[1] (at line 170); and not the bogus '0x20000'. I will test next week. [0] https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-addr.c;hb=HEAD#l42 [1] https://gitweb.gentoo.org/proj/sandbox.git/tree/libsandbox/wrapper-funcs/__wrapper_exec.c?h=v2.13#n170 On a side-note, AFAIS libsandbox's sb_check_exec wants to parse a subset of symbols of the dynamic symbol table(s). Wouldn't it be simpler to parse the section header array for 'hdr->sh_type == SHT_DYNSYM' and read the symbols of these section headers instead? May I open another bug for that, with test code and a patch on success (with fallback for current variant if no such type was found)? Created attachment 526370 [details, diff]
sandbox: crashfix no valid symbol name
It is possible that symbol name pointer point outside of the range of the string table array. Skip such symbols as glibc does.
Is this possibly related: https://bugs.chromium.org/p/chromium/issues/detail?id=884234 ? duping to a newer bug where i think this was debugged & addressed. the latest sandbox should work fine. https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=c8146cfbcd36f9be4a447bf057811fe2f6c543b2 *** This bug has been marked as a duplicate of bug 672918 *** |