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