Nico Grubert wrote at 2007-1-17 10:08 +0100:
... (gdb) thread 1 [Switching to thread 1 (Thread 47050976353024 (LWP 6613))]#0 0x00002acae8a3e202 in ?? () from /lib64/libc.so.6
(gdb) call PyRun_SimpleString("import sys, traceback; sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()")
Program received signal SIGSEGV, Segmentation fault. 0x000000000048fb9d in PyImport_AddModule (name=0x4d5ae9 "__main__") at Python/import.c:320 ... After I attached the pid "6613", Zope does not answers anymore until I quit "GDB". Is this the normal behavior?
Any idea, why no '/tmp/tb' logfile is created?
Because, the program get a SIGSEGV before it could create the file. I found that this is often the case when you call Python functions from GDB. My hypothesis is that this happens because in the thread where the Python function is called some important invariant is not met. E.g. almost all Python functions expect to be called only when the global interpreter lock (GIL) is held. But, this is the case at most in a single thread of Zope's multiple threads. For Zope debugging at C level, I therefore avoid calling Python functions directly but use emulations on the C level. Following are GDB commands to display the value of a Python string object ("ps") and to display the Python stack frame information in an "eval_frame" (C level) call frame ("pfr"). 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 lineno end define lineno set $__co = f->f_code set $__lasti = f->f_lasti set $__sz = ((PyStringObject *)$__co->co_lnotab)->ob_size/2 set $__p = (unsigned char *)((PyStringObject *)$__co->co_lnotab)->ob_sval set $__li = $__co->co_firstlineno set $__ad = 0 while ($__sz-1 >= 0) set $__sz = $__sz - 1 set $__ad = $__ad + *$__p set $__p = $__p + 1 if ($__ad > $__lasti) # break -- interpreted as "breakpoint" set $__sz = -1 end if ($__sz >= 0) set $__li = $__li + *$__p set $__p = $__p + 1 end end printf "%d\n", $__li end -- Dieter