interpreter crashes

[Barry A. Warsaw]

>>>>> "PR" == Paul Rubin <phr-n2001d at nightsong.com> writes:

    PR> Anthony Baxter <anthony at interlink.com.au> writes:
    >> OK.  I'll see if I can upload the dumps to an online server,
    >> then open a SourceForge bug.
    >>  If you can put the gdb backtraces there as well, it will make
    >> people's life easier.

    PR> The backtraces aren't very informative.  The evaluator is
    PR> crashing, almost certainly due to data corruption having
    PR> happened sometime earlier.  But sure, I'll include them.

    >> Sure - at the moment I've got a wierd little obscure bug in
    >> Python2.1.1 that's triggered by Zope. I'm running with a
    >> ZEO-server/ZEO-clients setup, so I'm running the ZEO server
    >> (which needs to stay up) with a nogc version of 2.1.1, and the
    >> ZEO clients (which need GC to handle the RestrictedPython code)
    >> with the gc-enabled version of python. Occasionally (about
    >> every 12-24 hours of runtime) a ZEO client will crash, but as
    >> they're behind a load balancer, it's invisible to the end user.

    PR> I'm not sure what RestrictedPython is--something different
    PR> from Rexec?  A 3rd party extension module?  If you're getting
    PR> crashes that frequently that's closer to reproducability than
    PR> what I've seen so far.  Maybe you can add some instrumentation
    PR> to find out what's causing the crashes.  One of the malloc
    PR> tracing libraries might be a reasonable place to start.

    PR> I've also been wondering whether it could make sense to modify
    PR> the gc to check the correctness of all ref counts when the gc
    PR> runs.  However I haven't yet looked at the gc code enough to
    PR> tell whether this is practical.