#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: | ||
| 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)
Change History (20)
by , 18 years ago
| Attachment: | screen1.png added |
|---|
by , 18 years ago
| Attachment: | screen2.png added |
|---|
by , 18 years ago
| Attachment: | screen3.png added |
|---|
by , 18 years ago
| Attachment: | gdb serial output.txt added |
|---|
comment:1 by , 18 years ago
| Component: | System/libroot.so → System/Kernel |
|---|---|
| Priority: | normal → critical |
| Summary: | Assert fails in libroot / malloc → Random memory trashing |
by , 17 years ago
| Attachment: | sleep_loop.sh added |
|---|
by , 17 years ago
| Attachment: | shell loop crash.txt added |
|---|
by , 17 years ago
| Attachment: | shell loop crash 2.txt added |
|---|
comment:2 by , 17 years ago
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.
comment:3 by , 17 years ago
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:5 by , 17 years ago
I don't know if it's the same bug, but there are still issues with hrev21487. See attachment.
by , 17 years ago
| Attachment: | new batch.zip added |
|---|
comment:6 by , 17 years ago
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 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Should be fixed, at least it's no longer reproducible - and there were quite a number of bug fixes in that regard...
comment:8 by , 17 years ago
It seems a bit more stable but I can still crash the system without too much effort.
comment:9 by , 17 years ago
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.
follow-up: 11 comment:10 by , 17 years ago
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.
What you're experiencing is a VM bug that randomly (but rarely) trashes memory of fork/exec applications.