19/60 Test #19: gmock_no_rtti_test ...................... Passed 0.02 sec Start 20: gtest-death-test_test 20/60 Test #20: gtest-death-test_test ...................***Failed 0.07 sec Start 21: gtest_environment_test 21/60 Test #21: gtest_environment_test .................. Passed 0.01 sec Start 22: gtest-filepath_test ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 13.0-desktop_20170828-210912 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.4.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) emerge -qpv dev-cpp/gtest [ebuild N ] dev-cpp/gtest-1.8.0 USE="-examples {-test}" ABI_X86="(64) -32 (-x32)"
Created attachment 491614 [details] emerge-info.txt
Created attachment 491616 [details] dev-cpp:gtest-1.8.0:20170831-213105.log
Created attachment 491618 [details] emerge-history.txt
Created attachment 491620 [details] environment
Created attachment 491622 [details] etc.portage.tbz2
Created attachment 491624 [details] LastTest.log.bz2
Created attachment 491626 [details] logs.tbz2
Created attachment 491628 [details] temp.tbz2
Created attachment 491630 [details] tests.tbz2
(In reply to Toralf Förster from comment #0) > 19/60 Test #19: gmock_no_rtti_test ...................... Passed 0.02 > sec > Start 20: gtest-death-test_test > 20/60 Test #20: gtest-death-test_test ...................***Failed 0.07 > sec > Start 21: gtest_environment_test > 21/60 Test #21: gtest_environment_test .................. Passed 0.01 > sec > Start 22: gtest-filepath_test Thanks for the report. I'm finally able to reproduce this. It only seems to occur on my end when running portage over the network and with usersandbox enabled in FEATURES.
gtest-death-tes[22872]: segfault at 7fb6c2475d58 ip 00007fb6c20ceb37 sp 00007fb6c2475d50 error 6 in libsandbox.so[7fb6c20ca000+13000](In reply to Peter Levine from comment #10) > (In reply to Toralf Förster from comment #0) > > 19/60 Test #19: gmock_no_rtti_test ...................... Passed 0.02 > > sec > > Start 20: gtest-death-test_test > > 20/60 Test #20: gtest-death-test_test ...................***Failed 0.07 > > sec > > Start 21: gtest_environment_test > > 21/60 Test #21: gtest_environment_test .................. Passed 0.01 > > sec > > Start 22: gtest-filepath_test > > Thanks for the report. I'm finally able to reproduce this. It only seems > to occur on my end when running portage over the network and with > usersandbox enabled in FEATURES. And from dmesg: gtest-death-tes[22872]: segfault at 7fb6c2475d58 ip 00007fb6c20ceb37 sp 00007fb6c2475d50 error 6 in libsandbox.so[7fb6c20ca000+13000]
Peter, I suppose you're familiar with gdb? ;-) Given sandbox is mostly unmaintained, it would be nice if you could try to see where it fails and if it's implementation fault or just stupid code upstream.
PR: https://github.com/gentoo/gentoo/pull/5605
(In reply to Michał Górny from comment #12) > Peter, I suppose you're familiar with gdb? ;-) Given sandbox is mostly > unmaintained, it would be nice if you could try to see where it fails and if > it's implementation fault or just stupid code upstream. I have limited experience with gdb. I'm not that familiar with the inner workings of sandbox. I understand that it works via LD_PRELOAD to handle system calls. I have been testing a single test with GDB over SSH via: > GTEST_BREAK_ON_FAILURE=1 gdb --args /var/tmp/portage/dev-cpp/gtest-1.8.0/work/googletest-release-1.8.0-abi_x86_64.amd64/googlemock/gtest/gtest-death-test_test --gtest_filter="*ThreadsafeDeathTestInChangedDir*" When I set > set environment LD_PRELOAD=/usr/lib/libsandbox.so in GDB it triggers test failure, and when omitted the test succeeds. When 'testing::GTEST_FLAG(death_test_style)' is set to "threadsafe", death tests are implemented as a call to 'clone()' which then executes the single test via 'execve()'. Looking at strace output, it seems that where there is a supposed to be a call to 'execve()', in the sandboxed test, there is a segfault. In the coming few days I'll try to use GDB to narrow down the problem.
(In reply to Peter Levine from comment #10) > It only seems > to occur on my end when running portage over the network and with > usersandbox enabled in FEATURES. Actually, it seems to just be related to usersandbox. After further inspection with GDB, I can observe the problem but am not quite sure what's causing it. When running > GTEST_BREAK_ON_FAILURE=1 gdb --args /var/tmp/portage/dev-cpp/gtest-1.8.0/work/googletest-release-1.8.0-abi_x86_64.amd64/googlemock/gtest/gtest-death-test_test --gtest_filter=TestForDeathTest.ThreadsafeDeathTestInChangedDir and setting > set follow-fork-mode child it shows that 'clone()' is called to spawn another thread, which then calls 'execve()' with arguments to run itself in non-threaded mode. If run in a sandbox shell, by the time it gets to 'before_syscall()' (in libsandbox.c) and initializes the stack array 'char at_file_buf[SB_PATH_MAX]' (which is 8192 bytes on my system), 'at_file_buf' can't be accessed. `print at_file_buf` in gdb prints "Cannot access memory at address 0x7fdcf94c9de0". And indeed, that memory is not a valid memory location on the process' virtual memory map. Its stack is located at '7ffffffdd000-7ffffffff000' so it doesn't look like a stack overflow. I'll continue to try and debug further.
OK. It appears that the memory from mmap() to be use as the child's stack with clone() is way to small. It's the size of a page (4032 bytes on my end). Indeed, the address of the stack array causing the segfault is within a page away from the stack's end. I presume that it's so small because clone() only has to execute one routine with the call to execve(). But the sandbox wrapper environment clearly requires much more stack space. After editing the stack size to something more sane like 139264, compile, and test, all tests pass even in sandbox. I'll submit a bug report to gtest in the next couple of days.
You may also want to try a newer (masked) sandbox version if you haven't done that already.
(In reply to Michał Górny from comment #17) > You may also want to try a newer (masked) sandbox version if you haven't > done that already. I've tried both sandbox-2.11-r5 and sandbox-2.10-r4. Upstream PR: https://github.com/google/googletest/pull/1274
@Michał Górny Please take a look at the PR at https://github.com/gentoo/gentoo/pull/5605 when you get a chance. I've been adding to it. Upstream will likely take forever with this. They may decide not to even fix this on their end, as it might be their opinion that they shouldn't have to alter their thread's stacksize for a downstream wrapper function. In that case, I could simply maintain the patch downstream or, if it comes to it, alter libsandbox's execve wrapper function to immediately fork its own thread with ample stackspace at invocation.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c611133fd67da12a870fb9a64c8e8ae298df0e42 commit c611133fd67da12a870fb9a64c8e8ae298df0e42 Author: Peter Levine <plevine457@gmail.com> AuthorDate: 2017-09-25 21:37:13 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2018-01-09 16:10:00 +0000 dev-cpp/gtest: Fix test failure with sandbox Bug: https://bugs.gentoo.org/629620 Package-Manager: Portage-2.3.6, Repoman-2.3.2 .../files/gtest-1.8.0-increase-clone-stack-size.patch | 14 ++++++++++++++ dev-cpp/gtest/gtest-1.8.0.ebuild | 1 + dev-cpp/gtest/gtest-9999.ebuild | 1 + 3 files changed, 16 insertions(+)}
