Bug 264478 – sys-apps/sandbox-1.7: ISE when running static binaries in vforked children (make/fpc)

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Paul Mulders 2009-04-01 09:15:50 UTC]

after updating to sandbox 1.7 lazarus ebuild fails. 

Reproducible: Always

Steps to Reproduce:
1.update to sandbox 1.7
2.try to install lazarus
3.:(

Actual Results:  
>>> Starting src_compile
make -j5 -j1
ISE opendir(debian): No such file or directory
	abs_path: (null)
	res_path: (null)
/usr/lib/libsandbox.so[0x7f797b83f7e2]
/usr/lib/libsandbox.so[0x7f797b83f813]
/usr/lib/libsandbox.so[0x7f797b841061]
/usr/lib/libsandbox.so(opendir+0x3c)[0x7f797b84395c]
make[0x404a18]
make[0x404af9]
make[0x4051de]
make[0x408d5a]
make[0x40a29d]
make[0x40554b]
/usr/libexec/paludis/utils/emake: line 23:  5305 Aborted                 ${EMAKE_WRAPPER} ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@"
/usr/libexec/paludis/utils/emake: emake returned error 134

!!! ERROR in dev-lang/lazarus-0.9.26-r1:
!!! In src_compile at line 3479
!!! make failed!

!!! Call stack:
!!!    * src_compile (/var/tmp/paludis/dev-lang-lazarus-0.9.26-r1/temp/loadsaveenv:3479)
!!!    * ebuild_f_compile (/usr/libexec/paludis/2/src_compile.bash:54)
!!!    * ebuild_main (/usr/libexec/paludis/ebuild.bash:482)
!!!    * main (/usr/libexec/paludis/ebuild.bash:498)

diefunc: making ebuild PID 5204 exit with error
die trap: exiting with error.

[Comment 1 Harald van Dijk (RETIRED) 2009-04-01 17:26:40 UTC]

At first sight, this looks more like a sandbox bug than a lazarus bug.

[Comment 2 Paul Mulders 2009-04-01 18:47:24 UTC]

agreed, but I figured it was worth a look. maybe the ebuild does something the newer sandbox disallows that was allowed by 1.6 ...

[Comment 3 Lars Wendler (Polynomial-C) (RETIRED) 2009-04-01 22:01:52 UTC]

*** Bug 264469 has been marked as a duplicate of this bug. ***

[Comment 4 Nick Fortino 2009-04-02 05:07:39 UTC]

Add =dev-lang/fpc-2.2.2-r1 to the list of ebuilds broken by the new sandbox.

As one might expect, git bisect fingers the "libsandbox: initial support for tracing of static binaries via ptrace()" commit as the culprit in the fpc case.

[Comment 5 SpanKY 2009-04-02 08:16:07 UTC]

lazarus only fails because it runs fpc -- a static binary

[Comment 6 Paul Mulders 2009-04-02 09:41:04 UTC]

so how will this be addressed, if at all? 

[Comment 7 Andrew Church 2009-04-03 15:54:18 UTC]

Since this breaks (at least) any package that calls a static binary when building, might it not be appropriate to hardmask sandbox-1.7 until the issue is resolved?

[Comment 8 SpanKY 2009-04-03 17:00:47 UTC]

it breaks fpc, not "any static binary".  see the difference ?

[Comment 9 Andrew Church 2009-04-03 19:32:14 UTC]

No, because as I and another user noted in bug 264469, this (or a similar issue) breaks at least e2fsprogs, coreutils, and sandbox itself.

[Comment 10 SpanKY 2009-04-03 23:24:47 UTC]

Bug 264469 is not a dupe.  e2fsprogs is broken.  sandbox-1.7 is catching a valid bug there.

[Comment 11 Andrew Church 2009-04-04 03:04:12 UTC]

Posted the coreutils/sandbox ISE as bug 264816.

[Comment 12 Lars Wendler (Polynomial-C) (RETIRED) 2009-04-04 17:42:20 UTC]

*** Bug 264816 has been marked as a duplicate of this bug. ***

[Comment 13 SpanKY 2009-04-05 08:58:41 UTC]

stupid make likes to vfork before execing ... which triggered the bug in sandbox where the tracing code didnt expect to be running in vfork context.  so the parent now cleans itself up a bit before exiting.

http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=6333d6e81e9f298c9bf7030b1bda9e906656d8f6