[Stackless] The Odyssey begins...

Mike Fletcher mfletch at tpresence.com
Mon Oct 9 04:15:30 CEST 2000

Gave up on trying to create a debug version of Stackless (well, actually,
continuation is what defeated me, for some reason it kept using a different
integer type than everything else).  For now I'm using release versions
compiled with debug information... I had no idea you could just tell a
release configuration to include debug information when building...

First things first:
	The problem is not wxPython-related (I rewrote my applications to
not use wxPython (was surprisingly easy), the same crashes are occurring, no
change in symptoms).

The rest:
	The crashes are occurring in multiple places, the Object module from
Stackless' PyObject_Compare (most common), the Meta-kit database library's
row setattr function, and listobject.c's list_dealloc (in the testing so
far).  In the first two cases, the object being passed for processing seems
to have a mucked up type pointer, the pointer# isn't null, and may point to
just about anywhere in memory (inside or outside the process's memory
space).  This would be consistent with some observed Python-side errors
where single-character strings were suddenly pointing to arbitrary objects
and/or being rejected by builtin operations as being "not a string"
(addition of strings, string.join).

Some questions for the gurus (Chris mostly, but just in case anyone else
feels like answering):
	How do you find the current python lineno for a given call.  I don't
see anything obvious in the call stack, but I assume it's gotta be there for
exception raising (I want to see what objects are being passed in with
incorrect types, so that I can reduce the problem slightly).
	Is there anything funky going on with single-character string
slice/index operations?  I'm not absolutely positive, but my primitive trace
approach to narrowing the objects that may be causing the problem seems to
suggest that the corrupted objects are mostly single-character strings.  (At
least three different places in the code have complained about the types of
what should be single character strings.)
	Anyone know a decent way to set breakpoints such that a complex
system (~100 modules) will only stop when it goes berserk?  For that matter,
if I could just tell it to stop when it gets to the areas where the problem
is currently happening in the python code, there will only be a few dozen
iterations to "continue" through  before I get to a crash.
	Is this a possible scenario: Multiple python libraries somehow get
instantiated, the types are imported variously by different extension
modules, with the extension modules passing created integers/strings back to
the main system with their ob_type pointers pointing into effectively
"foreign" memory.  I've tried to make sure this is not happening (deleted
all save 1 python15.dll), but I'm not sure if there is way that the modules
might load the same library twice.

Okay, will get back to poking around now (C code seems wrong somehow, all
these pointers and references and one-character variable names, I want to go
back to Python :) ),

 Mike C. Fletcher
 Designer, VR Plumber
Stackless mailing list
Stackless at starship.python.net

More information about the Stackless mailing list