python2.1 SEGV on Solaris 2.7

Anthony Baxter anthony at interlink.com.au
Wed Oct 17 10:25:36 EDT 2001


> Looks like a stack overflow to me (with 128 stack frames). I somehow
> doubt that gdb correctly represents the function names, though:
> PyEval_CallObjectWithKeywords doesn't call itself recursively. Are you
> sure that:
> a) you've compiled python with debugging information?
> b) gdb really sees that python binary that causes the crash?
 
I'm pretty sure the python binary was stripped, and who knows what 
else. I recompiled it without stripping, and confirmed the -g was 
there, and got another crash from it - this time, the crash stack
is 371 frames deep!

Note that compiling without GC stops the crash, but isn't acceptable,
as some of the current Zope code is heavily cyclic, and needs the
GC to survive (leaks >> 100M/hour, otherwise).

The newer crash is a bit munged at the bottom, and it's possibly 
either because python was compiled with -g -O2 and some inlining 
happened, or, as you say, a stack overflow happened. I've rebuilt
again with killing -O2 and will see how that goes. 

> If there is a stack overflow in the gc, you may succeed using Python
> 2.1.1, or the 2.2 betas: much of the recursion in the gc has been
> removed (although I thought that already happened in 2.1).

Sorry, my bad - this was 2.1.1. As this is a heavily used production 
system, the thought of using 2.2alpha-whatever does not fill me with
warm happy thoughts :)
 
> If there is a true stack overflow in user code, you may "succeed" in
> calling sys.setrecursionlimit sometime early, lowering the current
> value. Instead of a crash, you'd get then a StackOverflow exception.

Hrm. That's an idea.
 
> You can also increase your stack size, see ulimit(1) for details.

It's already set to 8M. That should be mooore than enough... but I guess 
it's worth a shot.
 
> > gcc version 2.95.2 19991024 (release)
> That compiler should work fine; it is likely not the cause of the
> problem.

Ok dokey. It was a guess on my part.

Thanks for the ideas!
Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>   
It's never too late to have a happy childhood.





More information about the Python-list mailing list