Opened 15 years ago

Closed 5 years ago

Last modified 4 years ago

#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)

malloc-assert-fail.png (177.8 KB ) - added by Blub 15 years ago.

Download all attachments as: .zip

Change History (7)

by Blub, 15 years ago

Attachment: malloc-assert-fail.png added

comment:1 by Blub, 15 years ago

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).

comment:2 by pulkomandy, 9 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 waddlesplash, 9 years ago

Milestone: R1Unscheduled

comment:4 by axeld, 7 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:5 by waddlesplash, 5 years ago

Resolution: invalid
Status: assignedclosed

Indeed.

comment:6 by nielx, 4 years ago

Milestone: Unscheduled

Remove milestone for tickets with status = closed and resolution != fixed

Note: See TracTickets for help on using tickets.