RE: Backtrace extraction ONLY gdb

["Maucci, Cyrille" <cyrille.maucci@hp.com>]

Hi Joel

>> You'd then debug on a separate host using that core file. A few companies I know do that routinely.
On the principle I agree.
However, it gets complex when:
	. the core files are multi GB large and the 'separate' host is not located on the customer network.
	. you not only need the core files but the libs to debug the core. Indeed, you could argue to setup a 'replica' system to read the core file, but when you've got dozens of customers with dozens of different software versions, this becomes the nightmare.

This is why the method we had put in place years ago is a kind of automated gdb backtrace extraction upon core dump detection (ends up with a very small file a few KB at most) with more or less an automatic 'sending' of that file from the customer to the support team by mail.

If the backtrace is a 'known' backtrace or if the backtrace is enough for us to understand the problem, then no need to get the full core.
Upon rare circumstances, we need the full core (that represents maybe less than 5% of the cases).

Again, that is part of an efficient support line.

Thanks anyway
++Cyrille
 

-----Original Message-----
From: Joel Brobecker [mailto:brobecker@adacore.com] 
Sent: Wednesday, March 23, 2011 11:44 PM
To: Maucci, Cyrille
Cc: Eli Zaretskii; gdb@sourceware.org
Subject: Re: Backtrace extraction ONLY gdb

> >From what I read it gives a very 'raw' output, very far from the 
> >beautiful gdb backtrace with function names and function arguments 
> >values.

You would be indeed missing the function argument values.  But getting the function names from the addresses can be done later on, using a tool such as addr2line.

The best option, IMO, is to get your process to dump a core file.
You'd then debug on a separate host using that core file. A few companies I know do that routinely.

--
Joel