[Zope-dev] more on the segfault saga

[Leonardo Rochael Almeida]

On Wed, 2002-03-13 at 21:30, Matthew T. Kromer wrote:
> 
> On Wednesday, March 13, 2002, at 10:40 AM, Leonardo Rochael Almeida 
> wrote:
> >
> > What about patching Python to report the freed objects like you
> > mentioned on IRC? Also, how about turning on some flags in
> > gc.seg_debug()? Do you think we might be able to glance something by
> > seeing what objects where logged as freed or by storing them in
> > gc.garbage?
> >

setting gc.set_debug(gc.DEBUG_LEAK) floods your stderr in a way you can
only believe by seeing it. And it didn't give me any clue. the last
object freed was an instance method. Most everything running inside Zope
is an instance method or another...

> Well, what I'm thinking about doing is trying to patch the Py_DECREF 
> macro to record the free objects in a table and mark the freed memory 
> with a signal value.

Good thing it doesn't involve writing anything to stderr (right?),
otherwise if gc.DEBUG_LEAK is a flood I cannot even begin to imagine the
flood of PyDECREF messages...

If you can produce a patch, I'm more than willing to apply it.

> I'm worried about the python script aspects.  It's frustrating, because 
> I am not aware of anything in pythonscripts that should be 
> thread-dependent.

The way the bytecode versions of said PythonScripts are kept in memory,
perhaps? Although that's not likely, since each thread keeps its own
version of that, even when recompilation is needed, right?

In any event, Martijn Jacobs (a.k.a. instability case #3 :-) sees his
crashes in pure dtml methods, which could mean that PythonScripts are
inocent in this case... or not, since the segfault hits inside the gc,
which might be collecting something completely unrelated to the current
requests.

Questions:

If I call gc.disable() but run gc.collect() from time to time I get the
same effect, right?

In this case, where in the code would I put a call to gc.collect() to
get it to happen after the second phase of the two phase commit?

Another aproach: would it be possible to, from time to time, put zope in
a state where it enqueue new connections instead of servicing them while
waiting for the currently running requests to finnish, then run
gc.collect(), then start servicing requests again?

Cheers, Leo