Date: Tue, 28 Mar 2017 03:43:41 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 217138] head (e.g.) -r315870 for arm64: sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted" once swapped in after being swapped out (comment 10) Message-ID: <bug-217138-8-p3e9lbEhg3@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-217138-8@https.bugs.freebsd.org/bugzilla/> References: <bug-217138-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217138 --- Comment #33 from Mark Millard <markmi@dsl-only.net> --- Created attachment 181258 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D181258&action= =3Dedit Test program with thousands of 14 KiByte allocations The test program that has thousands of 14 KiByte allocations usually ends up with them all being zeroed in the parent and child of the fork. But I've had a couple of runs where a much smaller prefix was messed up and then there were normal, expected values. #define region_size (14u*1024u) . . . #define num_regions (256u*1024u*1024u/region_size) So num_regions=3D=3D18724, using up most of 256 MiBytes. Note: each region has its own 14 KiByte allocation. But dyn_regions[1296].array[0] in one example was the first normal value. In another example dyn_regions[2180].array[4096] was the first normal value. The last is interesting for being part way through an allocation's space. That but aligning with a 4 KiByte page size would seem odd for a pure-jemalloc issue. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217138-8-p3e9lbEhg3>