| 1 | | With BFS and block cache tracing enabled, the kernel only survives a few seconds of file operations. In the first session after I updated r32128 from a revision before the heap changes, Haiku crashed shortly after invoking "svn up" in my tree within Haiku. I rebooted and installed a clean build over my partition. In the session after that, I tried svn cleanup, which showed me corrupted parts of my tree. The second rm -rf some/part/of/the/source dumped me back into the kernel debugger, and the kernel crashed again in the BFS tracing when allocating a tracing entry (like the first time). The panic talked about two NULL pointers, if that is helpful, but the crashing seems to be very easy to reproduce anyway (I hope for you, too). Reverting just the r32074 changeset seems to have made the system stable again. |
| | 1 | With BFS and block cache tracing enabled, the kernel only survives a few seconds of file operations. In the first session after I updated to r32128 from a revision before the heap changes, Haiku crashed shortly after invoking "svn up" in my tree within Haiku. I rebooted and made sure I have a clean build on my partition. In the session after that, I tried svn cleanup, which showed me corrupted parts of my tree. The second rm -rf some/part/of/the/source dumped me back into the kernel debugger, and the kernel crashed again in the BFS tracing when allocating a tracing entry (like the first time). The panic talked about two NULL pointers, if that is helpful, but the crashing seems to be very easy to reproduce anyway (I hope for you, too). Reverting just the r32074 changeset seems to have made the system stable again. |
