Summary: | dev-cpp/gtest-1.9.0_pre20190607: googletest-death-test-test fails when run in sandbox | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rolf Eike Beer <eike> |
Component: | Current packages | Assignee: | Peter Levine <plevine457> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jstein, proxy-maint |
Priority: | Normal | Keywords: | PullRequest, TESTFAILURE |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://github.com/gentoo/gentoo/pull/12751 https://bugs.gentoo.org/show_bug.cgi?id=923013 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
Patch |
Description
Rolf Eike Beer
2019-08-18 17:51:54 UTC
does it run fine with -j1? > [32;01m*[0m Applying gtest-1.9.0_pre20190607-add-mmap-stack-flag.patch ...
> [33;01m*[0m Unable to trace static ELF: /usr/bin/patch: patch -p1 -f -s -g0 --no-backup-if-mismatch
> [A[256C [34;01m[ [32;01mok[34;01m ][0m
It doesn't look like it's applying the patch. I don't think this is a gtest problem.
(In reply to Peter Levine from comment #2) > > [32;01m*[0m Applying gtest-1.9.0_pre20190607-add-mmap-stack-flag.patch ... > > [33;01m*[0m Unable to trace static ELF: /usr/bin/patch: patch -p1 -f -s -g0 --no-backup-if-mismatch > > [A[256C [34;01m[ [32;01mok[34;01m ][0m > > It doesn't look like it's applying the patch. I don't think this is a gtest > problem. Can you reproduce the issue with FEATURES="-sandbox"? The problem is probably specific to SPARC (and maybe some other architectures)... (In reply to Arfrever Frehtes Taifersar Arahesis from comment #4) > The problem is probably specific to SPARC (and maybe some other > architectures)... The patch being applied, at the point at which the elf message is being emitted, conditionally passes MAP_GROWSDOWN to mmap if the stack grows downwards in memory. AFAIK, on sparc64 it does. The concern is whether the patch is actually being applied when the message 'Unable to trace static ELF: /usr/bin/patch' is being emitted. If not, it is an error with sandbox and/or sys-devel/patch that is unrelated to gtest. Otherwise, it is a problem with gtest and sandbox that can likely be solved by reverting the patch to its former behavior (passing a larger stack to clone()). I suppose rebuilding with FEATURES=-sandbox isn't really a solution since the problem the patch, itself, is supposed to fix is this very error. Perhaps one can test by ebuilding the 'prepare' stage, changing directory to ${S}, manually trying to patch, and then resuming to ebuild the 'test' stage and confirming it passes. If one can manually patch without issue and the 'test' stage passes, the problem is with sys-devel/patch and or gtest. Otherwise, I should likely revert the patch. Not sure if a testcase failure is enough reason to block stabilization. "Unable to trace static ELF" is a harmless message generated by sandbox when any static executable is called. These executables still do their job, just without sandbox protection. (In this case, you can test sys-devel/patch with USE="static"...) (In reply to Arfrever Frehtes Taifersar Arahesis from comment #6) > "Unable to trace static ELF" is a harmless message generated by sandbox when > any static executable is called. These executables still do their job, just > without sandbox protection. > (In this case, you can test sys-devel/patch with USE="static"...) I see. Does the test failure itself inhibit stabilization? It's really a corner-case of sandbox (AFAIK usersandbox) with a constrained stack in a call to clone(). Or should I push a PR with an alternate patch and resubmit a stabilization request? dev-cpp/gtest-1.9.0_pre20190607 has already been stabilized on sparc. If I understand correctly, the previous approach ('stack_size = getpagesize() * 10') has been working on sparc. I do not know if there is something special in implementation of stacks on sparc, or in implementation of mmap() on sparc... Created attachment 587386 [details, diff]
Patch
Rolf Eike Beer: Please test if this patch happens to help...
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #8) > dev-cpp/gtest-1.9.0_pre20190607 has already been stabilized on sparc. > > If I understand correctly, the previous approach ('stack_size = > getpagesize() * 10') has been working on sparc. > I do not know if there is something special in implementation of stacks on > sparc, or in implementation of mmap() on sparc... The patch was changed to a more simple approach, to have the mmaped memory auto-resize by passing the MAP_GROWSDOWN flag to mmap() on Linux platforms in which the stack grows downward in memory, instead of requesting a larger fixed-size mmaped region. It appears that that approach was a bad idea. I incorrectly assumed that the stack overflow bug was only an issue on such platforms. Works with the patch. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa4cea02ac7bb486979ce96d29b0dc6c76491184 commit aa4cea02ac7bb486979ce96d29b0dc6c76491184 Author: Peter Levine <plevine457@gmail.com> AuthorDate: 2019-08-20 05:56:41 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2019-08-21 05:06:55 +0000 dev-cpp/gtest: Fix test failure on sparc64 sparc64 exhibits the same usersandbox stack overflow bug and its stack can apparently grow upwards in memory. Revert back to allocating 10 pages of mapped memory for the offending call to clone(). Bug: https://bugs.gentoo.org/692464 Reported-by: Rolf Eike Beer <gentoo-bug@opensource.sf-tec.de> Package-Manager: Portage-2.3.71, Repoman-2.3.17 Signed-off-by: Peter Levine <plevine457@gmail.com> Signed-off-by: Joonas Niilola <juippis@gentoo.org> .../gtest-1.9.0_pre20190607-add-mmap-stack-flag.patch | 15 --------------- ...test-1.9.0_pre20190607-increase-clone-stack-size.patch | 13 +++++++++++++ dev-cpp/gtest/gtest-1.9.0_pre20190607.ebuild | 2 +- dev-cpp/gtest/gtest-9999.ebuild | 2 +- 4 files changed, 15 insertions(+), 17 deletions(-) |