Dumping the state of a deadlocked process

fumanchu fumanchu at amor.org
Sat Oct 7 19:48:17 CEST 2006


Dennis Lee Bieber wrote:
> On 6 Oct 2006 12:59:31 -0700, andre.naess at gmail.com declaimed the
> following in comp.lang.python:
>
> > I'm currently having some issues with a process getting deadlocked. The
> > problem is that the only way I can seem to find information about where
> > it deadlocks is by making a wild guess, insert a pdb.set_trace() before
> > this point, and then step until it locks up, hoping that I've guessed
> > right.
> >
> 	I presume the process is using threads? If it is truly deadlocked,
> then you must have some mutual calls to lock objects somewhere... It
> would seem that rather than just randomly inserting debug statements you
> should surround each call to a lock with statements.
>
> 	print "Locking xyz"
> 	xyz.acquire()	#or whatever the syntax is
> 	print "Locked xyz"
>
>
>
> 	print "Releasing xyz"
> 	xyz.release()
> 	print "Released xyz"
>
>
> 	You'd need something like that around any potentially blocking
> operation -- queue operations, subprocess operations, socket
> operations... Rather than print statements you may wish to implement it
> via the logging module.

If you don't mind a potentially large log file, use the pyconquer
module I maintain here: http://projects.amor.org/misc/wiki/PyConquer
which uses settrace to do the logging in a much more readable and
manageable way than printlining. Try an initial run using the default
settings to narrow down the culprit, and then a run with C events
turned on if the first run wasn't enough. It should help out even if
your program is not multi-threaded, but it realy shines with threads.
:)


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org

P.S. Oh, and ignore the times in the output for now; that's still work
in progress.




More information about the Python-list mailing list