KDL while expanding a file

[jackburton]

• Created a 200MB haiku image
• added this file to the image: ​http://www.bebits.com/bob/19550/BeOS5-DevTools.zip
• used dd to copy it to a partition
• ran unzip to expand the file.

After some time, I was thrown into KDL. Screenshots follow.

After the KDL, I can't create files any more onto that partition.

[jackburton]

Interestingly, I can't seem to be able to reproduce it inside qemu, so you'll have to wait a bit for the screenshot. Maybe it's related to our IDE driver ?

[jackburton]

KDL

[jackburton]

backtrace

[jackburton]

And sorry for the crappyness of the shots.

[jackburton]

Since it happens only on real hardware here, I'll share the configuration: it's a laptop, AMD Sempron 2600+, 512 Mb Ram (64 taken by the onboard graphic adapter, an unsupported sis chipset).

[jackburton]

Axel, I see that in bfs_free_cookie() we ReadLock() the inode, but since we mess with the index, shouldn't we WriteLock() instead ?

[jackburton]

BTW I could just reproduce on qemu.

[jackburton]

Using a writelock in bfs_free_cookie() fixes the problem.

[axeld]

I've fixed the locking issue in hrev20079, thanks for the note. However, I don't think this can really prevent the bug from happening; at least it doesn't look like the source of the problem. The index inode is of course write locked when updating it, so it should never crash in BPlusTree::SplitNode(). What do you think? How often did you try again?

[jackburton]

Replying to axeld:

However, I don't think this can really prevent the bug from happening; at least it doesn't look like the source of the problem. The index inode is of course write locked when updating it, so it should never crash in BPlusTree::SplitNode(). What do you think? How often did you try again?

I tried twice, once on real hardware and once on qemu. I can try again later, but before it was happening 100% of the times, on real hardware.

[jackburton]

Ok, I just could reproduce it again. It crashed again in the same function, but the backtrace looks different.

[jackburton]

new backtrace

[jackburton]

Apparently this was fixed with Ingo's 20402. I'll leave this open still for a while, though.

[jackburton]

Replying to jackburton:

Apparently this was fixed with Ingo's 20402. I'll leave this open still for a while, though.

Unfortunately it still applies. Although now the system hang completely instead of dieing in KDL.

[gotaku]

I also get dropped into KDL when I try to unzip BeOS5-DevTools.zip in VMWare. It doesn't always happen but it seems to more then not.

[serpentor]

I was dropped into KDL while unzipping BeShare.zip that I had just downloaded from BeBits. I am running build 20883 and have attached a picture of the stack crawl after the crash (unzip-kdl-sc1.jpg).

[jackburton]

Axel, with the patch I've sent you (BPlusTree::_SplitNode()), the behaviour of this bug has changed a bit (for the better ?): Now I can unzip almost all the zip file, although near the end it KDLs again with a different backtrace. Note that, near the point where it KDLd before, the system stalls for ~20 seconds with the cpu at 100%.

[jackburton]

new kdl

[jackburton]

Replying to jackburton:

Axel, with the patch I've sent you (BPlusTree::_SplitNode()), the behaviour of this bug has changed a bit (for the better ?): Now I can unzip almost all the zip file, although near the end it KDLs again with a different backtrace. Note that, near the point where it KDLd before, the system stalls for ~20 seconds with the cpu at 100%.

The above applies on vmware player (virtual machine with 128 MB RAM). On real hardware (512 MB RAM) I am able to unzip the file correctly.

[axeld]

Replying to jackburton:

Axel, with the patch I've sent you (BPlusTree::_SplitNode()), the behaviour of this bug has changed a bit (for the better ?)

How often did you try after the patch? It sounds a bit strange that a fixed memory leak could prevent the invalid memory access. But then, given the state of our current VM, maybe that indeed has the power to do it. Now it just looks like any other "out of memory" problem indeed.

[jackburton]

Replying to axeld:

How often did you try after the patch?

I tried at least six or seven times.

It sounds a bit strange that a fixed memory leak could prevent the invalid memory >access. But then, given the state of our current VM, maybe that indeed has the power >to do it.

Yeah, seemed strange to me too.

[gotaku]

I just tried it again after reading the above comments but I notice no change in the status of this bug. I still get an unhandled page fault when trying to unzip the beos devtools.

[axeld]

I fixed the original problem in hrev21480: the block cache might have freed blocks that were still in use due to a bug in BFS. Since the later reported out-of-memory KDL is the same as in bug #517, I'm closing this one now.