Closed werdahias closed 3 weeks ago
Exciting, this only seems to happen on 32 bit ARM or so. Can't reproduce this here. I'll take a look later what could be the problem
@werdahias Does this also happen on other 32 bit architectures, or other 32 bit ARM? This is armv5te which IIRC is armel in Debian terms. How did it behave on armhf?
I can't see anything obviously wrong in the code, so if it only fails on armel it might very well be a toolchain bug.
the test fails on armel, armhf and i386, so it seems very likely that it is 32-bit related: https://ci.debian.net/packages/r/rust-glib-macros/testing/i386/53651276/#L9055
I did a quick manual test and just that test case panics on i386 when executed manually using cargo test
. I didn't verify whether it just affects Debian's toolchain, or upstream's 1.82 as well.
Thanks, I'll give that a try on 32 bit x86 later.
I can reproduce it with the 1.82 toolchain from rustup with the i686-unknown-linux-gnu target too
Found the problem
84c951ef5a62 was simply wrong. Derived Boxed
types are not TransparentPtrType
(== equivalent to a pointer of their FFI representation), they're TransparentType
(== equivalent to their FFI representation).
thanks for the quick fix!
@werdahias I'll do another upload of 1.82 soonish, so the migration age counter will start over anyway, but it would be great if we could get this fixed in Debian quickly as well since it seems to be the main remaining blocker/regression for 1.82 :)
You can also update to 0.20.5 instead of backporting the patch
Bug description In Debian we enabled rustc to trigger the tests of crates which directly depend on it. glib-macros passed before but has regressed now on all 32-bit arches.
Backtrace