This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/19048] Avoid corruption of free_list
- From: "fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 08 Oct 2015 15:59:43 +0000
- Subject: [Bug malloc/19048] Avoid corruption of free_list
- Auto-submitted: auto-generated
- References: <bug-19048-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19048
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |fweimer at redhat dot com
--- Comment #8 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Florian Weimer from comment #7)
> Can you clarify if you mean âcorruptionâ or âcontentionâ? These two are
> very different things.
Disregard that, its corruption which leads to contention.
I looked at the downstream bug report (rhbz#1264189), and it is now clear that
free_list (in malloc/arena.c) is corrupted. It eventually turns into a
circular list, instead of being a stack. Once this happens, the code that
should pop an element from the stack in get_free_list keeps returning the same
arena again and again.
arena_thread_freeres makes free_list circular if the same arena is pushed on
the stack again because the next pointer is overwritten. This can happen if
threads share the same arena.
I think we need to go the arena reference counter route and push the arena on
the stack only if the reference counter hits zero. list_lock is global, so we
should avoid doing a list traversal while holding it.
I don't think this is a correctness issue. Observed malloc behavior is still
compliant, it's just much slower than it could be.
--
You are receiving this mail because:
You are on the CC list for the bug.