Opened 12 years ago
Closed 12 years ago
#8910 closed bug (fixed)
Kernel panic during usage + overwrote a file on BFS when paniced.
Reported by: | xray7224 | Owned by: | axeld |
---|---|---|---|
Priority: | blocker | Milestone: | R1/alpha4 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #8919, #8942 | |
Platform: | All |
Description
Hey,
I was programming on haiku and using running the code (python) when randomly I experanced a kernel panic. I have taken a photo of the panic and have the file with random data in (it looks like just binrary junk been dumped in there).
I am running on the nightly hrev44563, this isn't really reproducable (at least I don't think) but hopefully this info is enough.
Attachments (9)
Change History (27)
by , 12 years ago
Attachment: | Haiku-kernel-panic.jpg added |
---|
by , 12 years ago
Attachment: | IRCObjects.py added |
---|
comment:1 by , 12 years ago
Blocking: | 8919 added |
---|
comment:2 by , 12 years ago
Status: | new → in-progress |
---|
This is probably related to my latest changes to the block cache.
comment:3 by , 12 years ago
Priority: | normal → blocker |
---|---|
Resolution: | → fixed |
Status: | in-progress → closed |
Should be fixed in hrev44585.
by , 12 years ago
Attachment: | IMG0050A.jpg added |
---|
comment:5 by , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:6 by , 12 years ago
Status: | reopened → in-progress |
---|
Seems I need to have another look, thanks for testing!
comment:7 by , 12 years ago
FYI, ran into the same exact panic here while doing a build of webcore. Anything extra I can grab out of the kernel debugger that'd be of help?
comment:8 by , 12 years ago
Milestone: | R1 → R1/alpha4 |
---|
I got the same while running installer from a fresh install of haiku this morning. I think this is easy enough to get into to be an alpha4 blocker, more so if data corruption is involved.
by , 12 years ago
Attachment: | install_deps.sh added |
---|
Script that generates KDL, debug_server exceptions
comment:9 by , 12 years ago
hrev44598-gcc2h. attachment:install_deps.sh has reliably caused KDLs or debug_server errors.
Prior to each event, the partition in question would be cleaned with checkfs.
comment:11 by , 12 years ago
With initial testing, hrev44610-2h does not KDL during the install_deps.sh script. Thanks!
by , 12 years ago
Attachment: | hrev44610-2h-gdb-crash.txt added |
---|
userland crash during install_deps.sh on hrev44610-gcc2h
by , 12 years ago
Attachment: | minicom-hrev44610.cap added |
---|
serial log of KDL, shortly after userland crash on hrev44610-2h
comment:12 by , 12 years ago
Spoke to soon, sort of. While letting a while [ 1 -ge 0 ] ; do rm -rf dependencies ; bash install_deps.sh ; done
run, libtool crashed. While mucking around with gdb, Terminal locked up. Closing the Terminal window, which sparked the crash, Haiku KDL'd.
To note, libtool did crash on a previous run, but a KDL was not triggered. Upon rebooting Haiku (and later mounting /generated), there were many lines similar to KERN: bfs: replay block run 0:161:1 in log at 1654!
. checkfs /generated found and freed some blocks.
comment:13 by , 12 years ago
To make sure that the recently rebuilt optional packages are not at fault, I rolled back hrev44593's libtool + sed to libtool-2.4-r1a3-x86-gcc2-2011-05-17.zip and sed-4.2.1-r1a3-x86-gcc2-2011-05-17.zip. After letting while [ 1 -ge 0 ] ; do rm -rf dependencies ; sync ; bash install_deps.sh ; done
run for a bit, several programs crashed -- libtool, WonderBrush, and Tracker all within seconds of each other. Here is the serial debug output during the crashes. To note, the libpthread.so lines are from pkg-config/glib's configure test.
comment:14 by , 12 years ago
Blocking: | 8942 added |
---|
comment:18 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
Alright, then I assume this is a different issue; at least I can't imagine how those two can be connected unless the block cache is trashing memory.
File which was corrupted.