[Zope3-dev] Zope3+W2k+mingw=Python crash

[Dave Harris]

----- Original Message ----- 
From: "Tim Peters" <tim at zope.com>
To: "David Harris" <dpharris76 at msn.com>; <zope3-dev at zope.org>
Cc: "W.Osuch" <osuchw at ecn.ab.ca>
Sent: Saturday, January 17, 2004 7:07 PM
Subject: RE: [Zope3-dev] Zope3+W2k+mingw=Python crash


> [Dave Harris]
> > I completely misapprended the problem. Instead of a code problem, the
> > abort occurs during maintenance of the garbage collection chain. In
> > particular, cm_dealloc() makes the call:
> >
> >    _PyObject_GC_UNTRACK((PyObject *)cm);
> >
> > and the process collapses when the assignment to the previous element
> > link is attempted. The address of the previous element appears to be
> > 0xfffffffd (-3). Now I have to find out why.
>
> Descriptions in terms of the actual C structures and code would really 
> help.

Sorry about that. I had all of the necessary information under my 
fingernails and could easily passed it along.

> Without those details it requires too much pure guessing, but I'm betting
> the -3 you're seeing isn't an accident, and am about to milk that for all
> it's worth <wink -- but it could be worth a lot!>.
>

I was seeing strange values in gc_refs and -3 in gc_prev. It was ringing 
alarm bells for me too. That set me off looking at sizeof() which...

> and if your compiler disagrees about sizeof(PyGC_Head), accessing fields 
> of
> g won't work as intended.  sizeof(PyGC_Head) is 16 under MSVC.  Under most
> 32-bit compilers used on Linux, I believes it's 12.  If it's 12 under your
> compiler, then I'm betting it looks like so:

yields 12 for both the gc struct and (long double). What really had me going 
is that I could do something like:

g->gc.gc_refs = _PyGC_REFS_REACHABLE;

And I'd get the correct value back:

printf(" gc_refs = %08lx\n", (unsigned long)g->gc.gc_refs);


> There's one other possibility:  Zope's C code is traditionally careless
> about following the rules for extension modules, particularly in 
> respecting
> the rule that extension modules should never use the macro spellings of
> Python C API functions (those are technically reserved for use by the 
> Python
> core -- but with some irritating exceptions, which makes the rules darned
> hard to remember).
>
> If the above is really what's happening, then if instead of cm_dealloc
> doing:
>
>     _PyObject_GC_UNTRACK((PyObject *)cm);
>
> it did what it's supposed to do:
>
>     PyObject_GC_UnTrack((PyObject *)cm);
>

I had tried that as well and it cleared up the first abort only to expose a 
second abort during the unittest teardown().

There's another posting floating around which mentions my work-around.

Thanks for the information on the PyGC_Head structure size under Windows. 
The discrepancy certainly explains a lot. And thanks for your patience.

Dave Harris