You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, after investigating our CI failures, I concluded that the write test for max_background_threads wrote libc::size_t::default(), which is 0, thus causing division by zero in jemalloc function background_thread_create_locked():
staticboolbackground_thread_create_locked(tsd_t*tsd, unsignedarena_ind) {
assert(have_background_thread);
malloc_mutex_assert_owner(tsd_tsdn(tsd), &background_thread_lock);
/* We create at most NCPUs threads. */size_tthread_ind=arena_ind % max_background_threads;
I believe 996e5b3 is caused by this; indeed, with the patch below, and its disabling #[cfg] directives for mips64el removed, a thousand runs on our mips64el porter box didn't fail. I also suspect that fd6f565 was due to the same reason, since the ptr2str function doesn't seem to have any division, but I didn't test.
I've patched our package to write 1 instead (see its description for the investigation process), but the style might not be preferable.
The text was updated successfully, but these errors were encountered:
Hi, after investigating our CI failures, I concluded that the write test for
max_background_threads
wrotelibc::size_t::default()
, which is 0, thus causing division by zero in jemalloc functionbackground_thread_create_locked()
:I believe 996e5b3 is caused by this; indeed, with the patch below, and its disabling
#[cfg]
directives for mips64el removed, a thousand runs on our mips64el porter box didn't fail. I also suspect that fd6f565 was due to the same reason, since theptr2str
function doesn't seem to have any division, but I didn't test.I've patched our package to write 1 instead (see its description for the investigation process), but the style might not be preferable.
The text was updated successfully, but these errors were encountered: