* thread apply all - not working?
@ 2005-05-27 18:45 Louis LeBlanc
2005-05-27 19:15 ` Daniel Jacobowitz
0 siblings, 1 reply; 9+ messages in thread
From: Louis LeBlanc @ 2005-05-27 18:45 UTC (permalink / raw)
To: GDB
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: thread apply all - not working?
2005-05-27 18:45 thread apply all - not working? Louis LeBlanc
@ 2005-05-27 19:15 ` Daniel Jacobowitz
2005-05-27 19:24 ` Louis LeBlanc
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Jacobowitz @ 2005-05-27 19:15 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: thread apply all - not working?
2005-05-27 19:15 ` Daniel Jacobowitz
@ 2005-05-27 19:24 ` Louis LeBlanc
2005-05-27 19:30 ` Daniel Jacobowitz
0 siblings, 1 reply; 9+ messages in thread
From: Louis LeBlanc @ 2005-05-27 19:24 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: thread apply all - not working?
2005-05-27 19:24 ` Louis LeBlanc
@ 2005-05-27 19:30 ` Daniel Jacobowitz
2005-05-27 19:49 ` Louis LeBlanc
0 siblings, 1 reply; 9+ messages in thread
From: Daniel Jacobowitz @ 2005-05-27 19:30 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: thread apply all - not working?
2005-05-27 19:30 ` Daniel Jacobowitz
@ 2005-05-27 19:49 ` Louis LeBlanc
2005-05-27 19:57 ` Daniel Jacobowitz
0 siblings, 1 reply; 9+ messages in thread
From: Louis LeBlanc @ 2005-05-27 19:49 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: thread apply all - not working?
2005-05-27 19:49 ` Louis LeBlanc
@ 2005-05-27 19:57 ` Daniel Jacobowitz
2005-05-27 20:13 ` Louis LeBlanc
2005-05-27 20:18 ` Louis LeBlanc
0 siblings, 2 replies; 9+ messages in thread
From: Daniel Jacobowitz @ 2005-05-27 19:57 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: thread apply all - not working?
2005-05-27 19:57 ` Daniel Jacobowitz
@ 2005-05-27 20:13 ` Louis LeBlanc
2005-05-28 0:12 ` Daniel Jacobowitz
2005-05-27 20:18 ` Louis LeBlanc
1 sibling, 1 reply; 9+ messages in thread
From: Louis LeBlanc @ 2005-05-27 20:13 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: thread apply all - not working?
2005-05-27 19:57 ` Daniel Jacobowitz
2005-05-27 20:13 ` Louis LeBlanc
@ 2005-05-27 20:18 ` Louis LeBlanc
1 sibling, 0 replies; 9+ messages in thread
From: Louis LeBlanc @ 2005-05-27 20:18 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: thread apply all - not working?
2005-05-27 20:13 ` Louis LeBlanc
@ 2005-05-28 0:12 ` Daniel Jacobowitz
0 siblings, 0 replies; 9+ messages in thread
From: Daniel Jacobowitz @ 2005-05-28 0:12 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-05-28 0:12 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-27 18:45 thread apply all - not working? Louis LeBlanc
2005-05-27 19:15 ` Daniel Jacobowitz
2005-05-27 19:24 ` Louis LeBlanc
2005-05-27 19:30 ` Daniel Jacobowitz
2005-05-27 19:49 ` Louis LeBlanc
2005-05-27 19:57 ` Daniel Jacobowitz
2005-05-27 20:13 ` Louis LeBlanc
2005-05-28 0:12 ` Daniel Jacobowitz
2005-05-27 20:18 ` Louis LeBlanc
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).