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