What do you want to hear? It's down to the "tedious bug finding - bug fixing" part. Yes, that's the boring stuff.
The latest thing I have done is having spend around 12 hours of not finding a non-existing bug in icon/workbench that, in the end, turned out to be a bug in MungWall. The story itself is funny (well, not so much after having missed 7h of sleep, but...), so here we go.
One of our fellow betatesters reported MungWall hits from icon. I could not reproduce. He went that far of supplying a winUAE snapshot which allows to reproce them (yuck. I like the real stuff. Yuck, Windows! Eeek.). Anyhow, hits show up. It looked like icon was damaging the rear mungwall of memory allocations. After 4h of debugging, it looked like icon was writing into non-allocated memory. Strangely, the bug went away also after downgrading layers to v40. A bug in V45 layers? Really?
Debugging went on... I could see the allocations. Of course, every time you boot allocations are a bit different, so it is *really really hard* to reproduce the problem such that you could set a breakpoint at a specific place. After another 7h of debugging, it turned out that the memory was allocated ok, there was no corruption due to task switching or inter-task dependency, and all the hits were "bogus". After another hour of debugging I finally found the culprit, and the reason.
MungWall! Layers V37!
Now, here is the story. The CBM developers of layers had the "great" idea to allocate the cliprects of layers in one continuous memory chunk ("AllocMem(sizeof(struct ClipRect) * 5,...)
" and then split this chunk into pieces, and release them individually. Which is a bit against the protocol of exec/AllocMem, and which is a really stupid thing to do as it really throws another fragmentation bomb on the system. But anyhow... MungWall would scream about this b*llsh*t, and for that reason, MungWall includes a workaround by not munging memory if the allocation comes from layers, just to be tolerant. Which is all nice, except that V45 doesn't have this problem. Actually, even layers V40 doesn't have it. So the workaround is not even actually needed in first place.
But how could this impact icon? I'm not debugging layers here, right? Due to a matter of bad luck and just coincidence, MungWall now believed that the icon.library allocation code comes from layers, though classified the icon.library (actually exec) memory release call as regular. This is because icon as well as layers are "loadmodule'd" and for that reason, the resident list, which is checked by MungWall, is a bit "unusal", so the mungwall heuristics of detecting "this PC belongs to layers" failed.
Now, what happend now is that MungWall did not create a mungwall upon allocation (as, this was supposed to be layers) but checked the mungwall upon the memory release (as it looked harmless). Result? No Mungwall on memory release, as none was created in first place -> Big bad warning!
Morale of the story: Choose debugging tools wisely, and select tools that are still maintained. MuGA is aware of the layers problem, and includes a workaround, which is of course disabled for later releases of layers. Wipeout is also still maintained, and doesn't have the problem. The problem wouldn't have popped up if it would have been one of the two.
Old legacy debugging tools with bugs suck big time. 8h to be precise.
Now this is the stuff I like to read about!
You protest but you know you loved every minute Thomas.
