Reference Counting Woes in Python 1.5.2! Help!

[Mark Hammond]

> I am using Visual C++ 6. It has debug libraries that are catching this
> problem printing an error message and quitting. When I go to release
version
> of code, I get access violations and then the code quits. Alas, what I'd
> like is to see the access violation location in source code, but the
darn
> debug library gets in the way!

It shouldnt be doing this!  An access violation when running under debug
build should definately break into the debugger, and definately does for
me.

You may be seeing Py_FatalError() being called.  This just prints a
message and calls "exit()", which does silently die.

Post Python 1.5, this routine as a block:

#ifdef _DEBUG
    DebugBreak()
#endif

You could try adding that to Python 1.5.2.  Then, in debug builds, a
Py_FatalError() will also break into the debugger.

> Has anyone else debugged pesky reference count problems in Visual C++
with
> Python 1.5.x and come out on the winning end? Your help or tips or
> suggestions on how to debug this sort of thing would be most welcome!

I find reference underflows easier to work with generally than leaks.  But
you definately need the exception in the VC debugger.  The symptoms are
generally that other code will die when trying to use the object with the
bad reference.  This can usually tell you at least the _type_ of the
object in question.

Another good hint - when re-running the same program multiple times under
VC, you almost always get identical addresses allocates between multiple
runs.  For example, if one run shows that object at address "0x123456" has
the ref count bug, restarting the program and rerunning under the debugger
will almost certainly give the same pointer the same address.  This makes
it easier to "back-step" through the offending code in multiple debugging
sessions. (eg, next step after determining the above may be to set a
break-point whenever "*(int *)0x123456" (ie, the objects reference-count)
changes.

Mark.