Quoting aaron@...749...:
I experience this quite often and mostly while debugging new effects.
But I have never been able to find steps to reproduce it. For me, crashes seem to be much less frequent when running through gdb, so it is hard to make a backtrace too.
I know there are some premature frees of (non-garbage-collector-managed) memory lurking in the codebase, but I've been unable to localize them yet.
There's a bug assigned to me -- I forget which one exactly, but it's got a file attached where if you follow the instructions in the bug you can just watch elements of the display fill with "junk" as memory is (wrongly) reused for other things.
The visible junk is showing up in the paint server buffers, but unfortunately that doesn't mean the bug is in the paint server code...
It could just mean that some other unreleated part of the code freed memory prematurely, and continued to use that memory even after it had subsequently been given to a paint server.
Frankly, I suspect livarot (don't I always?), but the only part of the code that I can actually rule out is the stuff that uses the garbage collector.
[ The garbage collector maintains a separate heap from the system heap that the paint servers use, and this sort of erroneous reuse isn't generally possible across heaps. ]
I'd really like to nail this stuff down before the release, because I'm sure it's behind an awful lot of obscure crashes. :/
[to all on the list] Any ideas for further tracking things down?
-mental