Bug#1093200: librsvg: FTBFS on mips64el: error: failed to acquire jobserver token; Caused by: Bad address (os error 14)

[Fabian Grünbichler]

re-adding debian-mips@ and the bug ;)

> Matthias Geiger <werdahias at riseup.net> hat am 16.01.2025 11:55 CET geschrieben:
> On Thu, 16 Jan 2025 11:45, Simon McVittie <smcv at debian.org> wrote:
> >Source: librsvg
> >Version: librsvg/2.59.2+dfsg-1
> >Severity: serious
> >Tags: ftbfs
> >Justification: fails to build from source (but built successfully in the past)
> >X-Debbugs-Cc: debian-rust at lists.debian.org, debian-mips at lists.debian.org
> >User: debian-mips at lists.debian.org
> >Usertags: mips64el
> >Control: block 1091629 by -1
> >
> >librsvg/2.59.2+dfsg-1 failed to build on mips64el across multiple retries,
> >most recently in
> ><https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.59.2%2Bdfsg-1&stamp=1736998842&raw=0>.
> >The end of its output looks like this, during dh_auto_build:
> >
> >> [14/15] /usr/bin/meson --internal exe --unpickle /build/reproducible-path/librsvg-2.59.2+dfsg/obj-mips64el-linux-gnuabi64/meson-private/meson_exe_cargo_wrapper.py_ea39adf033191d3f6abd46936a8fd06c312c29f5.dat
> >> warning: `/build/reproducible-path/librsvg-2.59.2+dfsg/.cargo/config` is deprecated in favor of `config.toml`
> >> note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
> >>    Compiling syn v2.0.72
> >>    Compiling gdk-pixbuf-sys v0.20.0
> >>    Compiling pixbufloader-svg v0.0.1 (/build/reproducible-path/librsvg-2.59.2+dfsg/gdk-pixbuf-loader)
> >> error: failed to acquire jobserver token
> >>
> >> Caused by:
> >>   Bad address (os error 14)
> >> warning: build failed, waiting for other jobs to finish...
> >...
> >> FAILED: gdk-pixbuf-loader/libpixbufloader_svg.so
> >
> >Earlier build attempts had a similar error either at the same point in
> >the build, or at a diferent point, during dh_auto_test:
> >
> >> https://buildd.debian.org/status/fetch.php?pkg=librsvg&arch=mips64el&ver=2.59.2%2Bdfsg-1&stamp=1734507441&raw=0
> >> ␛[1m␛[32m   Compiling␛[0m cairo-sys-rs v0.20.0
> >> ␛[1m␛[32m   Compiling␛[0m librsvg-c v2.59.2 (/<<PKGBUILDDIR>>/librsvg-c)
> >> ␛[1m␛[32m   Compiling␛[0m gdk-pixbuf v0.20.0
> >> ␛[1m␛[31merror␛[0m␛[1m:␛[0m failed to acquire jobserver token
> >>
> >> Caused by:
> >>   Bad address (os error 14)
> >> ␛[1m␛[33mwarning␛[0m␛[1m:␛[0m build failed, waiting for other jobs to finish...
> >
> >The error message "failed to acquire jobserver token" seems to come from
> >rustc or cargo, so I think this FTBFS bug should probably be reassigned
> >to rustc for investigation by the mips64el porting team.
> This is a known bug on mips64el with rust. loupe already ran into this 
> too; also swayosd ran into this:
> [0]
> >"Bad address" seems like it ought to mean EFAULT, which would seem to
> >indicate that rustc/cargo or some dependency of rustc/cargo is passing
> >a dangling pointer to a system call, or some similar problem?
> >
> Not sure tbh.
> >librsvg is a key package and is required by most of our desktop
> >environments, for its use in rendering SVG icons and wallpaper. If this
> >FTBFS cannot be fixed or worked around, we will have to look into doing
> >architecture-specific removals from mips64el, because it isn't sustainable
> >for mips64el to be holding more widely-used architectures hostage -
> >but if it is removed, most of the desktop ecosystem will go with it.
> >
> 
> Givebacks on mips64el semt to work; but I am not surewhat the underlying 
> cause is  here. Note that current rustc on mips64el in exp ran into the 
> same issue.

not the one in experimental (that one has a different mips64el issue atm), but it did hit it in the past. firefox-esr ran into it as well (https://bugs.debian.org/1087809) as did loupe (https://bugs.debian.org/1086028), and git triggered it in a unit test as well with no rust involved:

https://buildd.debian.org/status/fetch.php?pkg=git&arch=mips64el&ver=1%3A2.45.2-1.2&stamp=1731806317&raw=0 (grep for 'bad address')

relevant quotes from IRC from that:

20:45:50 <f_g> XXX: the original log looks like read(2) returns EFAULT, according to the man page that means the buffer being read into is outside of the accessible address sapce
20:46:19 <f_g> which is weird, given that it's declared right above the read with a 16k size
20:46:31 <f_g> assuming the error message and the single location my grep turned up actually line up
20:46:53 <f_g> (line 72 of builtin/upload-archive.c)
21:12:24 <f_g> yeah, seems weird. I mean, that test in particular also seems weird, it sets a limit of 500k and the test output says the minimum for that limit is 1M, and the test data is 1M ;)
21:12:47 <f_g> so maybe that causes some edge case, but why that would only affect mips64el I don't know
21:13:47 <f_g> nothing there screams mips64el specific to me so far, but I am far from an expert for such things :)

notable the git issue back then was not reproducible on eberlin, and a give back "solved" it by virtue of being scheduled on a different buildd (after failing in a different fashion on yet another buildd):

https://buildd.debian.org/status/logs.php?pkg=git&ver=1%3A2.45.2-1.2&arch=mips64el

I kind of assumed all of the above are the same underlying (hardware?) issue, and cargo just has a particular code/memory access pattern that triggers it more often.. but maybe the two are unrelated, and it is actually two bugs.. I did take a cursory glance at the job token in cargo/jobserver and nothing there looked problematic..