1 |
With an individual report of it fixing graphicsmagick build, this is |
2 |
now unmasked into ~arch. |
3 |
|
4 |
Happy festivities |
5 |
|
6 |
|
7 |
Ühel kenal päeval, R, 30.12.2016 kell 00:22, kirjutas Mart Raudsepp: |
8 |
> Hello, |
9 |
> |
10 |
> So I provided a patch for a sandbox bug hitting bigger projects using |
11 |
> -export-symbols-regex with a long list of object files. 3 months ago. |
12 |
> Bug has been there since forever, reported 15 months ago, with some |
13 |
> good clues to what's up since 9 months. |
14 |
> It has been sitting there, collecting dust, with no action from |
15 |
> sandbox@ whatsoever. As such, I plan to finally non-maintainer push |
16 |
> this fix straight to ~arch as a sandbox-2.10 revision bump once I |
17 |
> have |
18 |
> my months old GPG machine tree and system updated (this week or early |
19 |
> next week). And 2.11, but because that is still p.masked due to it |
20 |
> causing issues for XUL stuff (with analysis of what's going on also |
21 |
> available since a while now), that's going to be a p.masked revbump |
22 |
> alongside the 2.11 masks. |
23 |
> If I can't do my gnome-builder bumps that depends on this right away, |
24 |
> I |
25 |
> might let it simmer in p.mask for some hours or days too, especially |
26 |
> if |
27 |
> I see some sort of sandbox@ action appearing or some valid objections |
28 |
> by the time I get to it. |
29 |
> |
30 |
> This is the bug I have fix for: |
31 |
> https://bugs.gentoo.org/show_bug.cgi?id=553092 |
32 |
> |
33 |
> libtool ends up running "nm -B" with the long list of object files as |
34 |
> arguments and saves the result in a temporary file (which it'll apply |
35 |
> the regex to then), but various shells in some environments |
36 |
> (including |
37 |
> bash-4.3 and dash) end up trying to glob it and check if it's a dir, |
38 |
> calling opendir with the whole commandline as argument. If that is |
39 |
> longer than 8196 characters, sandbox gets confused because it |
40 |
> internally uses PATH_MAX*2 buffers, it gets cut and things fall over |
41 |
> in |
42 |
> ways I'm not interested in finding out deeper. |
43 |
> |
44 |
> At least gnome-builder-3.20+ and graphicsmagick are affected for some |
45 |
> (might depend on what their shell is doing). |
46 |
> |
47 |
> Because of this, gnome-builder hasn't seen version bumps, while the |
48 |
> existing version in tree (3.18, it didn't use so many object files in |
49 |
> the linker line quite yet back then to trigger the bug) are |
50 |
> completely |
51 |
> unusable with current stable gtksourceview and co. |
52 |
> |
53 |
> So, any objections with me pushing in the sandbox revbumps? |
54 |
> |
55 |
> |
56 |
> PS: I'm sure our mozilla team would appreciate also help with sandbox |
57 |
> bug 580726, which is a bug in the ptrace fallback, which now gets |
58 |
> triggered with the p.masked sandbox 2.11 due to some inherent issues |
59 |
> with the default non-ptrace code that were hit in Chrome OS project |
60 |
> thing doing some own memory management (and so it fallbacks more |
61 |
> often, |
62 |
> when it finds custom memory allocation stuff based on some |
63 |
> heuristics). |
64 |
> The ptrace fallback gets now used with 2.11 for firefox and co as |
65 |
> well |
66 |
> (probably due to jemalloc usage), and that fallback sandbox codepath |
67 |
> is |
68 |
> apparently buggy for its more complex case. Alternatively maybe these |
69 |
> heuristics could be less triggerhappy to fallback to ptrace. |
70 |
> |
71 |
> |
72 |
> Mart |
73 |
> |