#4164 closed bug (invalid)
assertion fails in malloc (rev 31961)
Reported by: | Blub | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | System/libroot.so | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I just hit an assertion in malloc() :( Adding a screenshot with some info printed in gdb, and the assertion (where you can see the file+line)
Unfortunately I cannot provide a small testcase, I'll try reproducing it with simple code, but I doubt I'll have much luck
Attachments (1)
Change History (7)
by , 15 years ago
Attachment: | malloc-assert-fail.png added |
---|
comment:1 by , 15 years ago
comment:2 by , 10 years ago
This assert is usually triggered by heap corruption, which can be caused by double free but also overwriting malloc guards. You can try running your program with libroot_debug to use a safer (but slower) allocator:
LD_PRELOAD=/system/lib/libroot_debug.so ./yourprogram
This one may be better at detecting the initial problem.
comment:3 by , 10 years ago
Milestone: | R1 → Unscheduled |
---|
comment:4 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 5 years ago
Milestone: | Unscheduled |
---|
Remove milestone for tickets with status = closed and resolution != fixed
Note:
See TracTickets
for help on using tickets.
seems like it was a double-free corruption, but I cannot really confirm that since I couldn't find the place where it actually happened.
I have a testcase where I was able to successfully double-free some data without any errors or assertion faults coming up, so I guess the errors occur some time too late.
After changing the data-layout of the program it didn't crash anymore (actually it is now optimized better since it doesn't fragment the memory as much)
I guess I'm just too used to glibc's huge and frightening "double free corruption" error message.
However, when I double-freed on purpose in my testcase (sometimes it did actually cause a crash) then it has always been a different assertion. (and it's always been the same different assertions)
Maybe if I have time to read through the malloc code I can add a check for double-free corruptions (if until then it's not already made).