Fully automating GDB (aka how to make canned command strings see the exit status)

Fully automating GDB (aka how to make canned command strings see the exit status)

[Alex Bennee]

Hi,

I've got a program I'm trying to debug that crashes on a very
intermittent basis. I suspect the core dumps I'm getting are incomplete
so I would like to try and catch the the crash live in gdb.

I figure a canned script to run the program is the answer. However how
do I tell if the program has exited successfully (in which case I can
run again) to hitting the SEG and staying put for when I come back in
the morning?


--
Alex, homepage: http://www.bennee.com/~alex/
TV is chewing gum for the eyes. -- Frank Lloyd Wright

Re: Fully automating GDB (aka how to make canned command strings see the exit status)

[Daniel Jacobowitz]

On Thu, Mar 16, 2006 at 05:11:21PM +0000, Alex Bennee wrote:
> Hi,
> 
> I've got a program I'm trying to debug that crashes on a very
> intermittent basis. I suspect the core dumps I'm getting are incomplete
> so I would like to try and catch the the crash live in gdb.
> 
> I figure a canned script to run the program is the answer. However how
> do I tell if the program has exited successfully (in which case I can
> run again) to hitting the SEG and staying put for when I come back in
> the morning?

There's lots of ways you can do this.  There's nothing in the GDB
command line scripting language that will work, but you can drive
GDB using something like "expect" instead; have the expect script stop
when it sees a SIGSEGV in the output.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Fully automating GDB (aka how to make canned command strings see the exit status)

[Larry Martell]

--- Alex Bennee <alexjb@transitive.com> wrote:

> how
> do I tell if the program has exited successfully (in
> which case I can
> run again) to hitting the SEG and staying put for
> when I come back in
> the morning?

Check the program's return status?

-larry

Re: Fully automating GDB (aka how to make canned command strings see the exit status)

[Ramana Radhakrishnan]

Hi,

Look at gdb scripts anyways. You could associate commands with
breakpoints. Quit on hitting a breakpoint on exit ?

break exit
commands
quit

Simple :

Have an external script that loops on this. In case the program hits a
SEGV gdb will get it and you have the context , else gdb exits.

Look at the while construct in gdb , maybe you can use that in case you
can't associate commands for breakpoints from scripts.

HTH

cheers
Ramana



> Hi,
>
> I've got a program I'm trying to debug that crashes on a very
> intermittent basis. I suspect the core dumps I'm getting are incomplete
> so I would like to try and catch the the crash live in gdb.
>
> I figure a canned script to run the program is the answer. However how
> do I tell if the program has exited successfully (in which case I can
> run again) to hitting the SEG and staying put for when I come back in
> the morning?
>
>
> --
> Alex, homepage: http://www.bennee.com/~alex/
> TV is chewing gum for the eyes. -- Frank Lloyd Wright
>


----
Ramana Radhakrishnan
GNU Tools
Codito Technologies

Re: Fully automating GDB (aka how to make canned command strings see the exit status)

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> On Thu, Mar 16, 2006 at 05:11:21PM +0000, Alex Bennee wrote:
>> Hi,
>>
>> I've got a program I'm trying to debug that crashes on a very
>> intermittent basis. I suspect the core dumps I'm getting are incomplete
>> so I would like to try and catch the the crash live in gdb.
>>
>> I figure a canned script to run the program is the answer. However how
>> do I tell if the program has exited successfully (in which case I can
>> run again) to hitting the SEG and staying put for when I come back in
>> the morning?
> 
> There's lots of ways you can do this.  There's nothing in the GDB
> command line scripting language that will work, but you can drive
> GDB using something like "expect" instead; have the expect script stop
> when it sees a SIGSEGV in the output.

Actually, if $_exitcode is not set (or is void) then no program has 
exited properly. Otherwise, $_exitcode is what it says on the tin.

Of course, there's no direct way to test for undefined variables (and 
anyway as soon as you look as them they are no longer undefined as 
such), and there is no way to compare void, but there is an indirect 
way. Use init-if-undefined to set $_exitcode to some unlikely value 
(999999 perhaps) and then check that.

The script might be

   run
   init-if-undefined $_exitcode = 999999
   if $_exitcode != 999999
     quit
   endif

That's untested, and GDB 6.4 only.

HTH

Andrew