Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1201 closed bug (fixed)

Random memory trashing

Reported by: jonas.kirilla Owned by: axeld
Priority: critical Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Assert fails in libroot / malloc.

See screenshots and GDB output.

http://svn.berlios.de/viewcvs/haiku/haiku/trunk/src/system/libroot/posix/malloc/

Searching for 'hoard' I found the following bug reports, but I can't say if any of them are related.

http://dev.haiku-os.org/ticket/1056 http://dev.haiku-os.org/ticket/326 http://dev.haiku-os.org/ticket/88

Attachments (9)

screen1.png (37.6 KB) - added by jonas.kirilla 12 years ago.
screen2.png (44.2 KB) - added by jonas.kirilla 12 years ago.
screen3.png (63.2 KB) - added by jonas.kirilla 12 years ago.
gdb serial output.txt (1.1 KB) - added by jonas.kirilla 12 years ago.
sleep_loop.sh (54 bytes) - added by jonas.kirilla 12 years ago.
shell loop crash.txt (1.6 KB) - added by jonas.kirilla 12 years ago.
shell loop crash 2.txt (54.3 KB) - added by jonas.kirilla 12 years ago.
DSC02644.JPG (375.3 KB) - added by jonas.kirilla 12 years ago.
another crash, now KDL
new batch.zip (23.7 KB) - added by jonas.kirilla 12 years ago.

Download all attachments as: .zip

Change History (20)

Changed 12 years ago by jonas.kirilla

Attachment: screen1.png added

Changed 12 years ago by jonas.kirilla

Attachment: screen2.png added

Changed 12 years ago by jonas.kirilla

Attachment: screen3.png added

Changed 12 years ago by jonas.kirilla

Attachment: gdb serial output.txt added

comment:1 Changed 12 years ago by axeld

Component: System/libroot.soSystem/Kernel
Priority: normalcritical
Summary: Assert fails in libroot / mallocRandom memory trashing

What you're experiencing is a VM bug that randomly (but rarely) trashes memory of fork/exec applications.

Changed 12 years ago by jonas.kirilla

Attachment: sleep_loop.sh added

Changed 12 years ago by jonas.kirilla

Attachment: shell loop crash.txt added

Changed 12 years ago by jonas.kirilla

Attachment: shell loop crash 2.txt added

comment:2 Changed 12 years ago by jonas.kirilla

The sleep_loop.sh script crashes within some tens of seconds. I'm not at all sure it is related to this bug report, but it's a simple case of fork/exec which fails.

Changed 12 years ago by jonas.kirilla

Attachment: DSC02644.JPG added

another crash, now KDL

comment:3 Changed 12 years ago by axeld

Can you still reproduce this with a revision after hrev21482? At least I let Qemu run this script for a couple of minutes now, and it didn't crash yet. Ever tried in Qemu? What type of system are you using for testing, anyway?

comment:4 Changed 12 years ago by rdaneel

Its happening in rev 21475. Tested in real hardware.

comment:5 Changed 12 years ago by jonas.kirilla

I don't know if it's the same bug, but there are still issues with hrev21487. See attachment.

Changed 12 years ago by jonas.kirilla

Attachment: new batch.zip added

comment:6 Changed 12 years ago by jonas.kirilla

I've tried Haiku in Qemu (or "Q") on MacOS X, but I've not tried any while looping in there. Will try to do so later. The midsummer weekend means downtime.

I usually test by rebooting to Haiku on my primary BeOS computer: a 2GHz Celeron, i845 chipset Asus motherboard, 512MB RAM, AGP, ATA. Nothing fancy. So far I haven't lost the BeOS partition to a run-away Haiku. :P

comment:7 Changed 12 years ago by axeld

Resolution: fixed
Status: newclosed

Should be fixed, at least it's no longer reproducible - and there were quite a number of bug fixes in that regard...

comment:8 Changed 12 years ago by jonas.kirilla

It seems a bit more stable but I can still crash the system without too much effort.

comment:9 Changed 12 years ago by jonas.kirilla

I suppose I may be hitting some other bug (unrelated to this ticket?):

vm_soft_fault: va 0xdeadbeef not covered by area in address space vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0xdeadbeef, ip 0x80055442, write 0, user 0, thread 0x2ed6 PANIC: vm_page_fault: unhandled page fault in kernel space at 0xdeadbeef, ip 0x80055442

Is there a way to find out from KDL where/what ip:0x80055442 is?

Having tested more, the system is indeed harder to crash. Performance degradation, having run applications, is still very much a problem though.

comment:10 Changed 12 years ago by axeld

Yes, just type "sc" in the kernel debugger to get a complete stack crawl. Please open a new bug report for this, though, as it indeed have nothing to do with the earlier bug :-) If you have a way to reproduce it, it would be helpful to mention that there, too.

BTW 0xdeadbeef is a special constant that the heap implementation will fill freed memory with; IOW someone is accessing memory that has already been freed.

comment:11 in reply to:  10 Changed 12 years ago by jonas.kirilla

Ok. Moving to bug report: #1322

Note: See TracTickets for help on using tickets.