When "Debug Spinning Zope" doesn't work
It used to be that on the rare occasions that Zope hung, I could use the recipe at http://zopelabs.com/cookbook/1073504990 to diagnose the problem (usually my own code was at fault). But, what does it mean when I get nothing at all from "info threads" in gdb? I get this on two different systems: system A: python2.3.5 zope 2.7.7 gdb 5.2-2 system B: python 2.3.4 zope 2.7.3 gdb 5.2-2 Lately this seems to happen regardless of whether Zope is responsive or not. e.g.: $ cat Z2.pid $ cat /zope/ZopeInstanceHome/var/Z2.pid 24161 $ sudo gdb python2.3 Password: GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) attach 24161 Attaching to program: /usr/local/bin/python2.3, process 24161 Reading symbols from /lib/libpthread.so.0...done. (snip copious output) Reading symbols from /usr/local/lib/python2.3/lib-dynload/itertools.so...done. Loaded symbols for /usr/local/lib/python2.3/lib-dynload/itertools.so 0x080775af in PyDict_GetItem (op=0x44d16934, key=0x401ae020) at Objects/dictobject.c:498 498 return (mp->ma_lookup)(mp, key, hash)->me_value; (gdb) info threads {gdb) That's it, nothing. It used to work for me. Any clues? -- Paul Winkler http://www.slinkp.com
Reading symbols from /usr/local/lib/python2.3/lib-dynload/itertools.so...done. Loaded symbols for /usr/local/lib/python2.3/lib-dynload/itertools.so 0x080775af in PyDict_GetItem (op=0x44d16934, key=0x401ae020) at Objects/dictobject.c:498 498 return (mp->ma_lookup)(mp, key, hash)->me_value; (gdb) info threads {gdb)
That's it, nothing. It used to work for me. Any clues?
Hi! Have you tried DeadlockDebugger product? Maybe it will tell you what is happening. So far it is working perfectly for me. -- Maciej Wisniowski
On Mon, Aug 01, 2005 at 07:09:03PM +0200, Maciej Wisniowski wrote:
Reading symbols from /usr/local/lib/python2.3/lib-dynload/itertools.so...done. Loaded symbols for /usr/local/lib/python2.3/lib-dynload/itertools.so 0x080775af in PyDict_GetItem (op=0x44d16934, key=0x401ae020) at Objects/dictobject.c:498 498 return (mp->ma_lookup)(mp, key, hash)->me_value; (gdb) info threads {gdb)
That's it, nothing. It used to work for me. Any clues?
Hi!
Have you tried DeadlockDebugger product? Maybe it will tell you what is happening. So far it is working perfectly for me.
Good idea, thanks! Will do. Some googling suggests that "info threads" returns nothing when gdb is run on a system that doesn't support threads. But that's absurd in this case. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2005-8-1 12:12 -0400:
... But, what does it mean when I get nothing at all from "info threads" in gdb?
That "gdb" does not understand the OS structures. I found that "gdb" has significant problems to understand "core" files of multithreaded applications and is easily confused by many normal behaviour of such applications. The first thing, I usually do, when I again hit a GDB problem is to upgrade GDB (in the hope that the new version learned a bit...) -- Dieter
participants (3)
-
Dieter Maurer -
Maciej Wisniowski -
Paul Winkler