[Zope-dev] Zope threads on 2.7.0, python 2.3.3

[Dieter Maurer]

Heimo Laukkanen wrote at 2004-5-25 22:46 +0300:
> ...
>> What does "Control_Panel --> Debug information" tells you
>> about the use of your connections (at the bottom of the page)?
>
>At the moment it said that only one opened connection and others were  
>none. I have no terminal access to the machines at the moment to check how  
>threads are behing at the moment.

That looks strange...
Maybe, the only running thread does not release the GIL?


>And then backtrace with gdb from those quiet threads


My most essential tools when analysing Python code in "gdb"
are the following two GDB command definitions.

def ps
x/s ({PyStringObject}$arg0)->ob_sval
end

def pfr
ps f->f_code->co_filename
ps f->f_code->co_name
p f->f_lineno
end

"ps" allows you to look at a Python String variable
and "pfr" can be called in "eval_frame" frames.
It tells you what code this frame is executing -- identified
by module and function. You cannot trust the "lineno" in
Python 2.3 (it is the start of the function not where you actually
are).


>~# gdb program 14552
>backtrace
> ...
>#7  0x080a22f6 in eval_frame (f=0x9b5ea24) at Python/ceval.c:2116

use "fr 7" to select this frame and then "pfr" to see where this is.

>...
>Another thread ( 14548 )
>
>
>#0  0x401153c4 in read () from /lib/libc.so.6
>#1  0x40029ae0 in __DTOR_END__ () from /lib/libpthread.so.0
>#2  0x412474f0 in nttrd () from  
>/opt/portaali/comp/oracle/lib/libclntsh.so.9.0
>#3  0x410fdcf8 in nsprecv () from  

Obviously, this is a call to Oracle.
Maybe, the GIL is not released?
> ...
>#14 0x40e13631 in Cursor_execute (self=0x4216fcd0, args=0x4017002c) at  
>src/dco2.c:3740

The GIL should have been released in the function above.
Check it for "Py_BEGIN_ALLOW_THREADS", "Py_END_ALLOW_THREADS"
around line 3740.

>....
>  PID: 14547
>
>#0  0x401153c4 in read () from /lib/libc.so.6
>#1  0x40029ae0 in __DTOR_END__ () from /lib/libpthread.so.0
>#2  0x412474f0 in nttrd () from  
>/opt/portaali/comp/oracle/lib/libclntsh.so.9.0

This, too is waiting for Oracle...

>PID: 14545
>
>#0  0x401153c4 in read () from /lib/libc.so.6
>#1  0x40029ae0 in __DTOR_END__ () from /lib/libpthread.so.0
>#2  0x412474f0 in nttrd () from  
>/opt/portaali/comp/oracle/lib/libclntsh.so.9.0
>#3  0x410fdcf8 in nsprecv () from  
This, too...


>PID: 14531
>
>#0  0x4011c7ee in select () from /lib/libc.so.6
>#1  0x40568cb4 in __DTOR_END__ () from  
>/opt/portaali/ContentManagement-1.0/python-2.3.3/lib/python2.3/lib-dynload/select.so
>#2  0x080e0e3f in PyCFunction_Call (func=0x4049636c, arg=0x426476e4,  
>kw=0x0) at Objects/methodobject.c:73
>#3  0x080a3beb in call_function (pp_stack=0xbffff11c, oparg=4) at  
>Python/ceval.c:3439
>#4  0x080a22f6 in eval_frame (f=0x9033f64) at Python/ceval.c:2116

Check where you are here (--> "pfr"). It may be the medusa/asyncore main loop.


You have several threads waiting for responses from Oracle.
Are you sure that "Control_Panel --> Debug information"
tells you only about a single ZODB connection?

-- 
Dieter