Bug#1093200: Some packages consistently FTBFS with EFAULT (Bad address) on most mips64el buildds

[Simon McVittie]

Control: retitle -1 Some packages consistently FTBFS with EFAULT (Bad address) on most mips64el buildds
Control: affects -1 + rustc src:librsvg src:swayosd src:git src:wings3d
Control: tags -1 + help

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.

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')

...

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

Yes, I think this does look like a more general mips64el
problem, which is certainly not a bug in librsvg specifically,
and probably not a bug in rustc either. This should probably be
reassigned to some suitable pseudo-package, but I don't know which
one (general? release.debian.org? ...) so for now I'm leaving it with
librsvg.

This is also preventing at least git from migrating to testing, if I'm
reading correctly. cc'ing the release team for visibility.

git has failed the majority of its builds on mips64el since 2023-12-31.

fatal: read error: Bad address
fatal: error in sideband demultiplexer

or

fatal: read error: Bad address
fatal: early EOF

in most of them. The fact that git basically works on every other
architecture would seem to point to this being something mips64el-specific,
either specific to these particular buildds (which I know we have had
problems with in the past) or a more general architecture/kernel/toolchain
problem.

wings3d also has a mips64el-specific build failure with a suspiciously

signal-dispatcher thread got unexpected error: efault (14)

I don't think it's fair to expect the maintainers of these particular
packages to be responsible for the health of mips64el.

smcv

[Uwe Kleine-König]

Hello,

Control: reassign -1 src:linux/6.1.76-1

I agree this looks like the kernel is at least involved in this problem.
Is someone able to do a bisect to help the kernel team to pinpoint the
issue?

Or does someone has a reproducer that also works for someone without
mips64el hardware (probably something involving qemu)?

Best regards
Uwe

[Sergei Golovan]

Hi!

Post by Uwe Kleine-König
Hello,
I agree this looks like the kernel is at least involved in this problem.
Is someone able to do a bisect to help the kernel team to pinpoint the
issue?
Or does someone has a reproducer that also works for someone without
mips64el hardware (probably something involving qemu)?

I've tried to reproduce the Erlang FTBFS in qemu (both on malta and
loongson-virt machines) and failed to do so.
Also, I've found a thread on linux-kernel mailing list, which might be
relevant (see [1]). It describes some EFAULT on
mips64 which were introduced roughly at the same time when Erlang
started to FTBFS. I've run the test they
suggested (on qemu on loongson-virt machine).

The test program is compiled using gcc-14 (14.2.0-16).

The test program aborts on kernels 6.1.0-29-loongson-3 (6.1.123-1) and
6.12.10-loongson-3 (6.12.10-1)

The test program does not abort on kernel 5.10.0-30-loongson-3 (5.10.218-1)

[1] https://lore.kernel.org/all/***@suse.de/T/

Cheers!