KDL with Iceweasel: ASSERT FAILED: newCommitment <= topCache->...

[jckarter]

Under recent nightlies on this MacbookAir4,1, when Iceweasel uses up most of RAM, I tend to hit KDLs in various places as shown in the attached photos. This is the same machine that I had reported #19224, #19225, and #19226 on, so it could be the Apple hardware memory corruption issue manifesting, though anecdotally, the machine appears to be stable while using Falkon with similar levels of memory usage.

[waddlesplash]

What hrev, please?

[jckarter]

Sorry, hrev58486.

[waddlesplash]

The first at least won't be due to memory corruption, rather it refers to an incorrect commitment accounting in some memory region (the assertion checks that the newly computed memory commitment is no larger than the region's actual size). It's been seen with Falkon and other applications in the past; the circumstances that trigger it are varied. I fixed a number of the causes over the last month and it's now much harder to trigger (or at least I no longer have a reliable way of causing it.)

The second and third are due to page reservation miscounting. Are you sure these are from hrev58486? Because there was a bug that could cause that in hrev58466 which was fixed in hrev58473.

[jckarter]

Ah, that makes sense; I had a few of these collected over the last week so some of them might be from older revisions. Let me see if I can reproduce a similar crash on what I’m running now.

[waddlesplash]

I haven't heard of anyone else being able to reproduce that bug since hrev58473; I could get it myself with some artificial memory-pressure tests here but after that fix I can't anymore.

The assertion failure KDL, though, is probably still around, though, as there aren't any recent changes there. That one is technically continuable, you can just "co" or Ctrl+D at the prompt and move on. But depending on what Iceweasel is doing, you may just get the same KDL dozens or hundreds of times in a row, so it may not really be practical to get out of it.

Is there a website or some usage pattern that triggers it reliably? Probably there's something specific Iceweasel is doing that runs up against the bug. (This one isn't memory-pressure related at all and can happen just as much on low memory usage as high.) I don't know if any other users have reported this with Iceweasel yet, which may indicate it's workload-specific somehow (web platform features that use some less-common codepath, maybe?)

[jckarter]

I tried to retrace my steps with Iceweasel under hrev58490, and couldn't manage to reproduce any of these crashes. I'll file again if I see this happen again and try to give fresher repro steps. Sorry for the noise.

[kim1963]

+1

This KDL reproduced in hrev58440-58475 and hrev58485, hrev58500

https://dev.haiku-os.org/attachment/ticket/19337/IMG_1875.jpeg

[waddlesplash]

Let's make this ticket about that, then. There was #19012 previously for this, but many of those issues are now fixed.

I think the remaining cases that don't work quite right here mostly have to do with fork() and how things behave when the forked process quits and the CoW'ed caches are merged, and also with SHARED areas. I'll have to do some testing about that.

In the meantime, the next builds of Iceweasel will have the forkserver enabled (and thus the main process shouldn't call fork anymore), so this will hopefully stop being a problem in practice once that comes out.