Home Original page

segfault. which module to blame?

D-Man dsh8290 at rit.edu
Thu Feb 15 20:01:54 EST 2001 
$ gdb `which python` core
<startup info from gdb>
gdb> backtrace
<backtrace from gdb>

Basically  gdb <executable image> <corefile>  will load the
executable's symbols (assuming it has some) and the core file.  It
will warn you if the exe has no symbols, or if the core came from a
different exe.  Backtrace will give you a trace similar to when a
python exception isn't caught (except it is for C, and thus much lower
level detail).

DDD (from gnu.org) is a nice (except that is uses motif) gui frontend
for gdb that will make browsing symbols, etc much easier (and you
won't need to learn yet another command line, yet).

HTH,
-D

On Thu, Feb 15, 2001 at 11:10:51PM +0000, Dan Parisien wrote:
| I am using shelve and a lot of threads to write to a dbm db. I implemented 
| my own row-level locking with dictionaries and counters and when I run a 
| test script that simulates extreme conditions (1500 threads, 10 writes 
| each) it segfaults 1/100 times it runs.
| 
| That kinda sucks, don't you think? I'm wondering if someone who has 
| experience could point me to which module is at fault: threading? or 
| shelve+dbm? or neither? :) Or maybe some technique on how to crawl through 
| the core file (I'm on mandrake gnu/linux 7.2 python 2.0.1)
| 
| I'm not expecting a correct answer, just a point in the right directions
| 
| Thank you :)
| Dan
|
More information about the Python-list mailing list