This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/19243] reused_arena can pick an arena on the free list, leading to an assertion failure and reference count corruption
- From: "nick.alcock at oracle dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 02 Mar 2016 15:34:15 +0000
- Subject: [Bug malloc/19243] reused_arena can pick an arena on the free list, leading to an assertion failure and reference count corruption
- Auto-submitted: auto-generated
- References: <bug-19243-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19243
--- Comment #9 from Nick Alcock <nick.alcock at oracle dot com> ---
The failure is a simple abort (if run with a boosted timeout so it doesn't just
time out):
error: pthread_create: Resource temporarily unavailable
Didn't expect signal from child: got `Aborted'
When compiled with lower optimization, as you suggest, there is unfortunately
no change: GDB shows massive numbers of thread creations, we start getting
'resource temporarily unavailable' errors, and then boom.
However... I think this may be a ulimit-related failure. My autobuilder
normally runs with soft RLIMIT_AS and RLIMIT_DATA of 7680000, to prevent
maddened builds or broken tests running the machines out of memory. If I lift
those to unlimited, the test passes and there are no longer any errors from
pthread_create() -- and of course a test like this will allocate a lot of vsz
in thread stacks for all those threads: I guess the real problem lies in
pthread_create()'s behaviour if its attempt to allocate a thread stack is
blocked by ulimits.
I'll file a new bug (and lift those ulimits for the glibc testsuite from now
on).
--
You are receiving this mail because:
You are on the CC list for the bug.