> I have also come to the conclusion that tracking down these memory > bugs is way too difficult right now. I tracked the above problem back > from a seg fault, which was resulting from a garbage value in the byte > code stream, which was triggered by adding a PMC to the free list > until I added a bunch of debugging code. With the debugging code, I > could see that the dead userargv PMC (that wasn't really dead because > it was on the system stack even though it would never get used again) > pointed to a PMC with a bogus type, but also the memory corruption was > now triggered by a stack push where the stack and some PMC incorrectly > shared a buffer. > > Or, in summary: these kinds of problems result in memory corruption > that is unlikely to be immediately fatal. > > I wonder if we could add something to GC_DEBUG that would mark all > dead Buffers and PMCs in an easily recognizable way, and then check > all live PMCs and Buffers to be sure that nothing they point to is > marked as being dead. (Right now, they all just unconditionally mark > things as "live for this DOD pass".)
+1 to something like this, I have been spent too many hours at the debugger trying to figure out some of these GC problems (one of them involving large buffers I still haven't solved) -Jason
