src/lib.rs | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 disable profiling except on amd64 i386, as did src:jemalloc

src/macros.rs | 31 17 + 14 - 0 !
1 file changed, 17 insertions(+), 14 deletions(-)

 work around max_background_threads being written 0
 Upstream disabled these tests for mips64el in 996e5b3926, without explanation;
 though right after fd6f565209, which did comment that test_ptr2str failed on
 mips64el due to SIGFPE, presumably for the same reason (I don't see how the
 ptr2str function in src/raw.rs would SIGFPE).
 .
 The symptom is the tests randomly fail due to SIGFPE. When I first saw this,
 it only appeared in s390x debci runs. The s390x porterbox, zelenka, didn't
 show this behavior (though now does with a bigger sample size), while debci
 worker ci-worker-s390x-01 does. Thanks to elbrus, I managed to pinpoint the
 culprit there, and seeing the SIGFPE disabling suspiciously similar,
 reproduced the same on the mips64el porterbox, eberlin. Now that the reason is
 clear, even on my own amd64 box with a few hundred runs.
 .
 Core dump points to jemalloc function background_thread_create_locked(), at
 the opening of which:
 	size_t thread_ind = arena_ind % max_background_threads;
 .. and here, `max_background_threads_write_test()` writes into the latter
 `libc::size_t::default()`, which is 0, thus dividing by zero. Due to the
 random order tests ran in parallel, this zero division may or may not occur.