thread apply all - not working?

thread apply all - not working?

[Louis LeBlanc]

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?

TIA
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

It is by the fortune of God that, in this country, we have three benefits:
freedom of speech, freedom of thought, and the wisdom never to use either.
    -- Mark Twain

Re: thread apply all - not working?

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: thread apply all - not working?

[Louis LeBlanc]

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 . . .


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

Biology is the only science in which multiplication means the same thing
as division.

Re: thread apply all - not working?

[Daniel Jacobowitz]

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'.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: thread apply all - not working?

[Louis LeBlanc]

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.

Re: thread apply all - not working?

[Daniel Jacobowitz]

On Fri, May 27, 2005 at 03:49:56PM -0400, Louis LeBlanc wrote:
> (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

That's the problem.  It's an error message; it stops "thread apply"
from continuing.

Jeff Johnston fixed this in CVS on 2004-11-05; try a CVS HEAD snapshot.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: thread apply all - not working?

[Louis LeBlanc]

On 05/27/05 03:57 PM, Daniel Jacobowitz sat at the `puter and typed:
> On Fri, May 27, 2005 at 03:49:56PM -0400, Louis LeBlanc wrote:
> > (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
> 
> That's the problem.  It's an error message; it stops "thread apply"
> from continuing.
> 
> Jeff Johnston fixed this in CVS on 2004-11-05; try a CVS HEAD snapshot.

I don't think it was fixed.  As I mentioned in my initial message, I'm
using GNU gdb 6.3.0.20050516-cvs, which should include anything checked
in in 11/04.


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

Performance:
  A statement of the speed at which a computer system works.  Or
  rather, might work under certain circumstances.  Or was rumored
  to be working over in Jersey about a month ago.

Re: thread apply all - not working?

[Louis LeBlanc]

On 05/27/05 03:57 PM, Daniel Jacobowitz sat at the `puter and typed:
> On Fri, May 27, 2005 at 03:49:56PM -0400, Louis LeBlanc wrote:
> > (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
> 
> That's the problem.  It's an error message; it stops "thread apply"
> from continuing.
> 
> Jeff Johnston fixed this in CVS on 2004-11-05; try a CVS HEAD snapshot.


BTW, this app is compiled with the following flags:

-ggdb -g3 -Wall -Wno-multichar -Wno-unused-function -mcpu=ultrasparc -O1 

The gcc version, as mentioned before, is gcc-3.3.

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

If mathematically you end up with the wrong answer, try multiplying by
the page number.

Re: thread apply all - not working?

[Daniel Jacobowitz]

On Fri, May 27, 2005 at 04:14:24PM -0400, Louis LeBlanc wrote:
> I don't think it was fixed.  As I mentioned in my initial message, I'm
> using GNU gdb 6.3.0.20050516-cvs, which should include anything checked
> in in 11/04.

That's the release branch.  You want 6.3.50.*.

-- 
Daniel Jacobowitz
CodeSourcery, LLC