This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: thread apply all - not working?
On 05/27/05 03:30 PM, Daniel Jacobowitz sat at the `puter and typed:
> On Fri, May 27, 2005 at 03:25:06PM -0400, Louis LeBlanc wrote:
> > On 05/27/05 03:15 PM, Daniel Jacobowitz sat at the `puter and typed:
> > > On Fri, May 27, 2005 at 02:46:46PM -0400, Louis LeBlanc wrote:
> > > > I'm having trouble getting stack traces on all threads from a core file.
> > > >
> > > > I was under the impression that "thread apply all bt" should get it, but
> > > > I only get the last thread.
> > > >
> > > > I am using GNU gdb 6.3.0.20050516-cvs on Solaris. The core was
> > > > generated by an app built with gcc 3.3.
> > > >
> > > > Am I missing something?
> > >
> > > Does info threads show multiple threads? If not, either the core dump
> > > only contains one thread, or GDB does not know how to extract threads
> > > from a core dump on Solaris - I think this used to work, but I don't
> > > know if it has been tried lately.
> >
> >
> > Of course, there are 104 threads in this particular core, and the app is
> > configured to run up to 500. The command I am trying gives me thread
> > 104, but no others. I am able to get stack traces if I explicity select
> > them one at a time, but with up to 500 threads, you can imagine how much
> > fun this will be . . .
>
> OK, that's progress. Please show me the entire output of 'thread apply all
> bt'.
(gdb) thread apply all bt
Thread 104 (process 6772575 ):
#0 0xfea1e574 in __tbl_2_big_digits () from /usr/lib/libc.so.1
#1 0xff34db00 in read () from /usr/lib/lwp/libthread.so.1
#2 0xfef86960 in snttread () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#3 0xfef842f0 in nttrd () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#4 0xfee3ec2c in nsprecv () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#5 0xfee43740 in nsrdr () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#6 0xfee2968c in nsdo () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#7 0xfeeafb74 in nioqrc () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#8 0xfefffe54 in ttcdrv () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#9 0xfeeb81e0 in nioqwa () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#10 0xfed3b5cc in upirtrc () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#11 0xfed8b64c in kpurcsc () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#12 0xfed5b104 in kpuexecv8 () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#13 0xfed5d2d4 in kpuexec () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#14 0xfed9a318 in OCIStmtExecute () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
#15 0x000e5234 in execute_statement (connID=1533288, stmntID=3, args=0xf837a650, dbTimingRec=0xf8379b80, inOpCode=18758) at dbase.c:873
#16 0x0002f1dc in handle_check (thread=0x759b30) at miniget.c:1044
#17 0x000e3134 in spawn (arg=0x759b30) at xpcthread.c:195
#18 0xff354978 in _lwp_start () from /usr/lib/lwp/libthread.so.1
#19 0xff354978 in _lwp_start () from /usr/lib/lwp/libthread.so.1
Previous frame identical to this frame (corrupt stack?)
#0 0xff024044 in ttcpip () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0
Just in case it makes any difference, here's the contents of my
~/.gdbinit file:
directory .
directory common/src
directory common/include
set print address
set print array
set print pretty
set pagination off
Lou
--
Louis LeBlanc dev@keyslapper.net
Fully Funded Hobbyist, KeySlapper Extrordinaire :þ
http://www.keyslapper.net Ô¿Ô¬
Key fingerprint = C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2
Experience varies directly with equipment ruined.