Is this the right list...

Is this the right list...

[aladdin]

to ask questions regarding how to use gdb?  The web site indicates it is for 
discussing enhancements, but I don't see a user list.  If it is, here's my 
question:

When a program goes off into a daemon, or an endless loop or whatever, how do 
you get gdb attention (i. e., get a prompt so you can stop/check/abort the 
program)?

TIA
anw

Re: Is this the right list...

[Joel Brobecker]

[yes, you can send questions about using GDB to this]

> When a program goes off into a daemon, or an endless loop or whatever, how do 
> you get gdb attention (i. e., get a prompt so you can stop/check/abort the 
> program)?

If GDB is still attached to your program, hitting control-c should
interrupt your program and allow you to see where it is. Otherwise,
your other option, if you are not attach, then just get the pid of
your program, and attach GDB to it using "attach <pid>".

The GDB documentation should provide you more details about this.
(my very first lesson at engineering school was RTFM :-)

-- 
Joel

Re: Is this the right list...

[aladdin]

Actually, I did (always do) RTFM before posting.  I've found that to be less 
hassle than subscribing to a list, but realize I may be in the minority with 
that opinion;-).

gdb is still attached to the program.  The program forks itself twice turning 
itself into a daemon, and gdb is set to follow the child fork.  It seems to 
do this fine.  Obviously, I would normally have set breakpoints to capture 
it, but forgot to do so in one case, and figured there must be a way to get 
gdb's attention again.

Neither ctl-c nor kill worked; I had to "kill -9" it.  I don't understand 
that; the only signal the user program is catching is SIGALRM (14?).

On Thursday 03 May 2007 21:40, Joel Brobecker wrote:
> [yes, you can send questions about using GDB to this]
>
> > When a program goes off into a daemon, or an endless loop or whatever,
> > how do you get gdb attention (i. e., get a prompt so you can
> > stop/check/abort the program)?
>
> If GDB is still attached to your program, hitting control-c should
> interrupt your program and allow you to see where it is. Otherwise,
> your other option, if you are not attach, then just get the pid of
> your program, and attach GDB to it using "attach <pid>".
>
> The GDB documentation should provide you more details about this.
> (my very first lesson at engineering school was RTFM :-)

RE: Is this the right list...

[Jude Moersdorf]

From the command line try sending a SIGSTOP to the process.  'kill
-SIGSTOP <pid>'

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
Behalf Of aladdin
Sent: Thursday, May 03, 2007 7:04 PM
To: gdb@sourceware.org
Subject: Re: Is this the right list...

Actually, I did (always do) RTFM before posting.  I've found that to be
less 
hassle than subscribing to a list, but realize I may be in the minority
with 
that opinion;-).

gdb is still attached to the program.  The program forks itself twice
turning 
itself into a daemon, and gdb is set to follow the child fork.  It seems
to 
do this fine.  Obviously, I would normally have set breakpoints to
capture 
it, but forgot to do so in one case, and figured there must be a way to
get 
gdb's attention again.

Neither ctl-c nor kill worked; I had to "kill -9" it.  I don't
understand 
that; the only signal the user program is catching is SIGALRM (14?).

On Thursday 03 May 2007 21:40, Joel Brobecker wrote:
> [yes, you can send questions about using GDB to this]
>
> > When a program goes off into a daemon, or an endless loop or
whatever,
> > how do you get gdb attention (i. e., get a prompt so you can
> > stop/check/abort the program)?
>
> If GDB is still attached to your program, hitting control-c should
> interrupt your program and allow you to see where it is. Otherwise,
> your other option, if you are not attach, then just get the pid of
> your program, and attach GDB to it using "attach <pid>".
>
> The GDB documentation should provide you more details about this.
> (my very first lesson at engineering school was RTFM :-)

Re: Is this the right list...

[aladdin]

Excellent!  Thanks.  Next time, I'll do that.

Now, I know this isn't the right list, but does anyone out there know of a 
forum or list for Electric Fence?  Or a better or more suitable product for 
finding memory problems?  I'm using gdb and Electric Fence and have a 
particularly pernicious memory bug that bombs out in the middle of strcmp in 
the bowels of the ODBC library.

On Friday 04 May 2007 11:43, Jude Moersdorf wrote:
> From the command line try sending a SIGSTOP to the process.  'kill
> -SIGSTOP <pid>'
>
> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of aladdin
> Sent: Thursday, May 03, 2007 7:04 PM
> To: gdb@sourceware.org
> Subject: Re: Is this the right list...
>
> Actually, I did (always do) RTFM before posting.  I've found that to be
> less
> hassle than subscribing to a list, but realize I may be in the minority
> with
> that opinion;-).
>
> gdb is still attached to the program.  The program forks itself twice
> turning
> itself into a daemon, and gdb is set to follow the child fork.  It seems
> to
> do this fine.  Obviously, I would normally have set breakpoints to
> capture
> it, but forgot to do so in one case, and figured there must be a way to
> get
> gdb's attention again.
>
> Neither ctl-c nor kill worked; I had to "kill -9" it.  I don't
> understand
> that; the only signal the user program is catching is SIGALRM (14?).
>
> On Thursday 03 May 2007 21:40, Joel Brobecker wrote:
> > [yes, you can send questions about using GDB to this]
> >
> > > When a program goes off into a daemon, or an endless loop or
>
> whatever,
>
> > > how do you get gdb attention (i. e., get a prompt so you can
> > > stop/check/abort the program)?
> >
> > If GDB is still attached to your program, hitting control-c should
> > interrupt your program and allow you to see where it is. Otherwise,
> > your other option, if you are not attach, then just get the pid of
> > your program, and attach GDB to it using "attach <pid>".
> >
> > The GDB documentation should provide you more details about this.
> > (my very first lesson at engineering school was RTFM :-)