Bytecode stack manipulations for weak objects

[Jerry James]

Last fall there were a number of crashes induced by Gnus with a patch in
place that adjusted the GC protection on the bytecode stack.  As I
recall, the intent was to stop protecting weak objects on the stack as
soon as possible so that they could be garbage collected.  The patch
apparently let some object(s) get collected too soon, while references
still existed.

What is the status of that patch?  Was the problem completely resolved,
or do we just have a workaround in place?

I ask because I have a masters student looking for a project.  She has
done some work with Datastreams, a local project for doing low-overhead
data collection.  We have used it very effectively within the Linux
kernel for both debugging and performance evaluation.  Now we are trying
to use it in user-level programs in a similar way.  I'm looking around
for a debugging problem that might benefit from being able to log events
very efficiently, then pass arbitrarily complex filters over the
recorded event stream.  If the bytecode stack patch and the associated
problems still exist, I thought that might be an interesting
application.  We would log bytecode stack manipulations, provoke the
crash, then filter the event stream backward to find out when protection
was removed for the address in question.

Failing that, can you think of any other XEmacs bugs that look very
difficult to track down by hand, but might benefit from this kind of
data recording and analysis?
-- 
Jerry James
http://www.ittc.ku.edu/~james/