#18451: Assertion failure (mutex was not actually locked) in libroot hoard
malloc
--------------------------------+-------------------------
Reporter: waddlesplash | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: System/libroot.so | Version: R1/beta4
Resolution: | Keywords:
Blocked By: | Blocking:
Platform: All |
--------------------------------+-------------------------
Comment (by pulkomandy):
So we're looking at this lock, I guess:
https://cgit.haiku-
os.org/haiku/tree/src/system/libroot/posix/malloc_hoard2/processheap.cpp#n203
Notice how the superblock is retrieved from the memory block being freed:
superblock *sb = b->getSuperblock();
This means a corrupt block (either because some data was overwritten, or
because the software is trying to free memory that was not allocated by
malloc) will result in a pointer not pointing to a superblock at all.
There is an assert to check if the superblock is valid, but the validation
done is quite weak:
- Two values (numBlocks and sizeClass) must be greater than zero
(effectively checking only the sign bit)
- numAvailable must be less than numBlocks
(block::isValid which is called earlier in the function is even worse, it
is just a "return 1" and there isn't much more that can be checked)
HEAP_DEBUG is not set so we don't have the _magic field which could be
used for a more reliable check. And the isValid function in the superblock
does not even try to uses that anyways.
So, is it possible that we are simply looking at an invalid superblock,
and the value being used is not at all a mutex, because we didn't actually
get a pointer to a superblock?
--
Ticket URL: <https://dev.haiku-os.org/ticket/18451#comment:6>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
