public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* working around batch mode command errors
@ 2012-10-28 22:28 Maucci, Cyrille
  2012-10-30 17:27 ` Jan Kratochvil
  2012-10-30 17:39 ` Pedro Alves
  0 siblings, 2 replies; 6+ messages in thread
From: Maucci, Cyrille @ 2012-10-28 22:28 UTC (permalink / raw)
  To: gdb; +Cc: Maucci, Cyrille

Hello gdb'ers,


I've got a batch script that is meant to be invoked on customer production systems, should a process dump a core file. The goal of this script is to quickly and easily collect and send to support people very basic information about the coredump, because :
1- that is often painful and slow to get the core file itself (and dependant libs) out of the system for in depth analysis.
2- most of the time information contained in the script output is enough for the source code owners to understand what the problem is.


So the script looks like this:

set pagination off
info sharedlibrary
info threads
up 128
info args
info locals
frame 0
info source
info args
info locals
info frame
info all-registers
print *this
thread apply all bt
thread apply all bt full
quit


One of the problem I have is that when frame 0 is not C++ code, "print *this" fails and the script aborts with the following error

Error in sourced command file:
No symbol "this" in current context.

And therefore all subsequent commands are not executed.
I wanted to know if there would be any possiblity to avoid halting on such errors.

An aside question would be is there any built-in commands allowing to do something like

for each frame do
info source
info args
info locals
info frame
info all-registers
print *this
done  


Thanks a bunch for your help
++Cyrille

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: working around batch mode command errors
  2012-10-28 22:28 working around batch mode command errors Maucci, Cyrille
@ 2012-10-30 17:27 ` Jan Kratochvil
  2012-10-30 17:39 ` Pedro Alves
  1 sibling, 0 replies; 6+ messages in thread
From: Jan Kratochvil @ 2012-10-30 17:27 UTC (permalink / raw)
  To: Maucci, Cyrille; +Cc: gdb

On Sun, 28 Oct 2012 23:28:32 +0100, Maucci, Cyrille wrote:
> Error in sourced command file:
> No symbol "this" in current context.
> 
> And therefore all subsequent commands are not executed.

Use:
	gdb <file
instead of
	gdb -x file


> An aside question would be is there any built-in commands allowing to do
> something like

Use ABRT or Apport which hook globally on system via
/proc/sys/kernel/core_pattern . You can also provide per-application custom
info dumpers.


Regards,
Jan

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: working around batch mode command errors
  2012-10-28 22:28 working around batch mode command errors Maucci, Cyrille
  2012-10-30 17:27 ` Jan Kratochvil
@ 2012-10-30 17:39 ` Pedro Alves
  2012-10-30 17:43   ` Tom Tromey
  1 sibling, 1 reply; 6+ messages in thread
From: Pedro Alves @ 2012-10-30 17:39 UTC (permalink / raw)
  To: Maucci, Cyrille; +Cc: gdb

On 10/28/2012 10:28 PM, Maucci, Cyrille wrote:

> One of the problem I have is that when frame 0 is not C++ code, "print *this" fails and the script aborts with the following error
> 
> Error in sourced command file:
> No symbol "this" in current context.
> 
> And therefore all subsequent commands are not executed.
> I wanted to know if there would be any possiblity to avoid halting on such errors.

There's no try/catch mechanism in the CLI unfortunately, but I think you could
come up with one in python gdb.  ISTR Tromey had a python command wrapper that
swallows CLI errors?

> An aside question would be is there any built-in commands allowing to do something like
> 
> for each frame do
> info source
> info args
> info locals
> info frame
> info all-registers
> print *this
> done  

Nope.  But could construct something like that using gdb's builtin python support.

-- 
Pedro Alves

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: working around batch mode command errors
  2012-10-30 17:39 ` Pedro Alves
@ 2012-10-30 17:43   ` Tom Tromey
  2012-11-01 20:30     ` Doug Evans
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Tromey @ 2012-10-30 17:43 UTC (permalink / raw)
  To: Pedro Alves; +Cc: Maucci, Cyrille, gdb

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> There's no try/catch mechanism in the CLI unfortunately, but I
Pedro> think you could come up with one in python gdb.  ISTR Tromey had
Pedro> a python command wrapper that swallows CLI errors?

Yeah, http://www.sourceware.org/ml/gdb/2010-06/msg00100.html

There's a more full-blown try/catch implementation in bugzilla.
That one isn't in Python.  I don't know why it never went in.

This seems to be a frequently requested feature.

Tom

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: working around batch mode command errors
  2012-10-30 17:43   ` Tom Tromey
@ 2012-11-01 20:30     ` Doug Evans
  2012-11-01 20:38       ` Tom Tromey
  0 siblings, 1 reply; 6+ messages in thread
From: Doug Evans @ 2012-11-01 20:30 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Pedro Alves, Maucci, Cyrille, gdb

On Tue, Oct 30, 2012 at 10:43 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>
> Pedro> There's no try/catch mechanism in the CLI unfortunately, but I
> Pedro> think you could come up with one in python gdb.  ISTR Tromey had
> Pedro> a python command wrapper that swallows CLI errors?
>
> Yeah, http://www.sourceware.org/ml/gdb/2010-06/msg00100.html
>
> There's a more full-blown try/catch implementation in bugzilla.
> That one isn't in Python.  I don't know why it never went in.
>
> This seems to be a frequently requested feature.
>
> Tom

I went looking for the bugzilla entry but couldn't find it.

try:
   gdb.execute (...)
except:
  pass

is just too much to type.
</sarcasm> :-)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: working around batch mode command errors
  2012-11-01 20:30     ` Doug Evans
@ 2012-11-01 20:38       ` Tom Tromey
  0 siblings, 0 replies; 6+ messages in thread
From: Tom Tromey @ 2012-11-01 20:38 UTC (permalink / raw)
  To: Doug Evans; +Cc: Pedro Alves, Maucci, Cyrille, gdb

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> I went looking for the bugzilla entry but couldn't find it.

http://sourceware.org/bugzilla/show_bug.cgi?id=8487

Doug> try:
Doug>    gdb.execute (...)
Doug> except:
Doug>   pass
Doug> is just too much to type.
Doug> </sarcasm> :-)

:)

We can have both try/catch and ignore-errors, if we want.

Tom

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-11-01 20:38 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-28 22:28 working around batch mode command errors Maucci, Cyrille
2012-10-30 17:27 ` Jan Kratochvil
2012-10-30 17:39 ` Pedro Alves
2012-10-30 17:43   ` Tom Tromey
2012-11-01 20:30     ` Doug Evans
2012-11-01 20:38       ` Tom Tromey

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