[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Non-maintainer sandbox patching
From:       Mart Raudsepp <leio () gentoo ! org>
Date:       2016-12-31 18:33:13
Message-ID: 1483209193.20987.1.camel () gentoo ! org
[Download RAW message or body]

With an individual report of it fixing graphicsmagick build, this is
now unmasked into ~arch.

Happy festivities


Ühel kenal päeval, R, 30.12.2016 kell 00:22, kirjutas Mart Raudsepp:
> Hello,
> 
> So I provided a patch for a sandbox bug hitting bigger projects using
> -export-symbols-regex with a long list of object files. 3 months ago.
> Bug has been there since forever, reported 15 months ago, with some
> good clues to what's up since 9 months.
> It has been sitting there, collecting dust, with no action from
> sandbox@ whatsoever. As such, I plan to finally non-maintainer push
> this fix straight to ~arch as a sandbox-2.10 revision bump once I
> have
> my months old GPG machine tree and system updated (this week or early
> next week). And 2.11, but because that is still p.masked due to it
> causing issues for XUL stuff (with analysis of what's going on also
> available since a while now), that's going to be a p.masked revbump
> alongside the 2.11 masks.
> If I can't do my gnome-builder bumps that depends on this right away,
> I
> might let it simmer in p.mask for some hours or days too, especially
> if
> I see some sort of sandbox@ action appearing or some valid objections
> by the time I get to it.
> 
> This is the bug I have fix for:
> https://bugs.gentoo.org/show_bug.cgi?id=553092
> 
> libtool ends up running "nm -B" with the long list of object files as
> arguments and saves the result in a temporary file (which it'll apply
> the regex to then), but various shells in some environments
> (including
> bash-4.3 and dash) end up trying to glob it and check if it's a dir,
> calling opendir with the whole commandline as argument. If that is
> longer than 8196 characters, sandbox gets confused because it
> internally uses PATH_MAX*2 buffers, it gets cut and things fall over
> in
> ways I'm not interested in finding out deeper.
> 
> At least gnome-builder-3.20+ and graphicsmagick are affected for some
> (might depend on what their shell is doing).
> 
> Because of this, gnome-builder hasn't seen version bumps, while the
> existing version in tree (3.18, it didn't use so many object files in
> the linker line quite yet back then to trigger the bug) are
> completely
> unusable with current stable gtksourceview and co.
> 
> So, any objections with me pushing in the sandbox revbumps?
> 
> 
> PS: I'm sure our mozilla team would appreciate also help with sandbox
> bug 580726, which is a bug in the ptrace fallback, which now gets
> triggered with the p.masked sandbox 2.11 due to some inherent issues
> with the default non-ptrace code that were hit in Chrome OS project
> thing doing some own memory management (and so it fallbacks more
> often,
> when it finds custom memory allocation stuff based on some
> heuristics).
> The ptrace fallback gets now used with 2.11 for firefox and co as
> well
> (probably due to jemalloc usage), and that fallback sandbox codepath
> is
> apparently buggy for its more complex case. Alternatively maybe these
> heuristics could be less triggerhappy to fallback to ptrace.
> 
> 
> Mart
> 

[prev in list] [next in list] [prev in thread] [next in thread]