>>> Neil Schemenauer wrote
> [I'm moving the discussion here from SF, using the tracker is too
> painful.]
ok. please CC me on any replies. =
current update - I applied the PyFrame_BlockSetup() fix for ceval.c
that Martin suggested, and so far I've had 4 processes running for
a couple of hours each, without any splattage. this doesn't necessarily
mean it's fixed - the time between failures has varied from 5 minutes to
12 hours over the last few days.
> The ob_type pointer must be getting cleared after the object has been
> added to the GC lists. The PyObject_IS_GC call in _PyGC_Insert would
> have segfaulted otherwise. Knowing the type of the object would be
> helpful in debugging the problem. I suggest reconsidering Martin's
> printf idea. You could add something like this to _PyGC_Insert:
I'll have a poke at this tomorrow, and see if it's possible at all -
the problem is that the boxes are part of a zope cluster that gets =
a _lot_ of hits (something over 1m/day) so that's a lot of objects...
I'm also going to have another go at getting purify to work on our
stripped down production servers.
=
> Debugging this type of problem is really hard (as you already know)
> because the effect of the bug is found so far away from the source.
*nod* I'm aware of it. =
thanks!
Anthony
-- =
Anthony Baxter <anthony@interlink.com.au> =
It's never too late to have a happy childhood.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4