#1718 closed bug (invalid)
malloc bugreport on Mozilla exit
Reported by: | fyysik | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | System | Version: | R1/pre-alpha1 |
Keywords: | Cc: | mattmadia@… | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
When starting SeaMonkey from terminal and then exit app at some time, complaint from libroot appears in terminal: "seamonkey-bin: src/system/libroot/posix/malloc/superblock.h:194:void BPrivate::superblock::putBlock(BPrivate::block *): getNumAvailable() < getNumBlocks() ./run-mozilla.sh: line 424: 192 Kill Thread "$prog" ${1+"$@"}"
I wish to know what happens from libroot/malloc POV, this problem may happen in BeOS aswell, as Mozilla for BeOS exit code (and bootstrap code btw) is neither standard nor trivial.
Attachments (1)
Change History (9)
follow-up: 3 comment:1 by , 17 years ago
comment:2 by , 17 years ago
The allocator likely has its own assert implementation that we might want to replace :)
follow-up: 4 comment:3 by , 17 years ago
Replying to bonefish:
where you could at least see the back trace. Was anything printed in the serial debug output (respectively syslog)?
Unfortunately my laptop lacks serial port (inspite there is "debug port" listed in BIOS - with resources which remind normal COM! very closely. That unfortunate Thinkpad R40e - very simplified model:(
comment:4 by , 17 years ago
Replying to axeld:
The allocator likely has its own assert implementation that we might want to replace :)
Unless I overlooked something, it doesn't. arch-specific.h includes <assert.h>.
Replying to fyysik:
Replying to bonefish:
where you could at least see the back trace. Was anything printed in the serial debug output (respectively syslog)?
Unfortunately my laptop lacks serial port (inspite there is "debug port" listed in BIOS - with resources which remind normal COM! very closely. That unfortunate Thinkpad R40e - very simplified model:(
As long as Haiku itself doesn't crash, you should have a syslog (/var/log/syslog). It is enabled by default.
by , 17 years ago
Attachment: | syslog_when_seamonkey_exited_with_malloc_assertion.zip added |
---|
comment:5 by , 16 years ago
Cc: | added |
---|
comment:6 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:7 by , 6 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
Indeed that's a double-free, so this needs to be reported to the BeZilla team.
comment:8 by , 5 years ago
Milestone: | R1 |
---|
Remove milestone for tickets with status = closed and resolution != fixed
That's an assert() in the memory allocator, probably caused by a double free(), free()ing not allocated memory, or some memory corruption. Actually the failed assert() should call the debugger(), where you could at least see the back trace. Was anything printed in the serial debug output (respectively syslog)?