Barry A. Warsaw
barry at zope.com
Mon Oct 29 07:41:08 CET 2001
>>>>> "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.
More information about the Python-list