On 15/10/12 10:30, Chris Samuel wrote: > The killer at the moment is that both ltrace and gdb (when told to > trace children) hang when python runs dash to run ldconfig which calls > ldconfig.real and that blocks - so I never get to the point where the > function gets called the first time.
It's actually Python -> dash -> ldconfig.real. Here's the gdb session: chris@chris-ultralap:~/Code/Ubuntu$ gdb /usr/bin/python GNU gdb (GDB) 7.5-ubuntu Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/python...Reading symbols from /usr/lib/debug/usr/bin/python2.7...done. done. (gdb) set detach-on-fork off (gdb) set follow-fork-mode child (gdb) set follow-exec-mode new (gdb) catch load /libXi/ Catchpoint 1 (load) (gdb) break XIQueryVersion Function "XIQueryVersion" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (XIQueryVersion) pending. (gdb) run /usr/bin/synaptiks Starting program: /usr/bin/python /usr/bin/synaptiks [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New process 3788] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Thread 0x7ffff6ccc700 (LWP 3788) is executing new program: /bin/dash [New process 3789] process 3789 is executing new program: /bin/dash process 3789 is executing new program: /sbin/ldconfig.real -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
