Opened 11 years ago

Closed 11 years ago

#1756 closed bug (fixed)

svn checkout results in panic() which in turn results in corrupted BFS

Reported by: anevilyak Owned by: axeld
Priority: normal Milestone: R1
Component: File Systems/BFS Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


If you attempt an svn checkout of the Haiku source tree from within Haiku, it relatively consistently panics into the kernel after roughly the same amount of progress in the checkout every time (in my case, in the middle of the glibc portion of libroot). The panic itself is unimportant (heap overgrew itself), as it's a known allocator issue. However, on reboot the partition is rendered unbootable, as the kernel claims to be unable to find the boot volume. Attempting to mount the partition with the bfs_shell in order to play back the BFS log produces the following output:

bfs: Replay log, disk was not correctly unmounted... run count: 1002310361, array max: 23, max runs: 126 bfs: Log entry has broken header! bfs: replaying log entry from 1976 failed: Unknown error 2147483664 bfs: could not initialize journal/block bitmap allocator! bfs: bfs_mount:127: Cannot allocate memory Error: Mounting FS failed: Cannot allocate memory

Leaving the partition still unusable. This corruption happened consistently across several runs of (reimage partition, boot, checkout, reboot).

Change History (3)

comment:1 Changed 11 years ago by mmlr

The panic shouldn't happen anymore, as we now got an actually working kernel heap that will grow to accommodate the memory use. Not sure about the BFS corruption, but I suppose this is going to be a bit difficult to reproduce now.

comment:2 Changed 11 years ago by anevilyak

Want me to try a checkout again to verify that?

comment:3 Changed 11 years ago by anevilyak

Resolution: fixed
Status: newclosed

Indeed, works now:

Checked out revision 26095. /boot/home/devel>

Note: See TracTickets for help on using tickets.