This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug malloc/19048] Avoid corruption of free_list


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]