Re: Compiling gnome-core 1.10 and gdk-pixbuf problems (different!)

[Telsa Gwynne <hobbit aloss ukuu org uk>]

On Tue, Nov 02, 1999 at 09:57:52PM -0800 or thereabouts, Gerry Chu wrote:
> wouldn't start. I tried using gdb but I couldn't figure out how to use it.

gdb is one of those programs designed for programmers, yes :) I
_think_ that the URL that comes up in the newer versions of Gnome 
when you crash something has details of how to use it, but I
can't find that page, and bugs.gnome.org is currently not talking
to me.

There's three easy (ish) ways to use gdb. For my money, the simplest 
use is Gnome menu->panel->add applet->utilities->tickastat and then
use the preferences dialogue box to tell tickastat to enable
the core dump module and to generate backtraces.

I'm not kidding. tickastat will spot a new core file, rename it
to something useful, and automatically run gdb and get a backtrace
for you :) 

You need to have it running at the time the core is formed, of
course, and I don't think it can do anything if a program crashes
and doesn't leave a core file behind.

And of course it requires Gnome to be working :)

The Mutt (plug plug) FAQ also tells you how to use gdb to generate a 
backtrace/stacktrace. (I'm sure there's a difference, but it eludes 
me). It's at http://www.fefe.de/muttfaq/faq.html. Again, this requires 
having the core file about - but it doesn't require Gnome to be working.

If you have a core file left in your home directory, then cd to
your home-directory, and type at a prompt (without the angle-brackets):

gdb <name of program> core 

You might need the full path in front of the program name, too. 

You get a copyright notice, a lot of "Reading symbols" stuff (the
more things you compile to be 'unstripped' or 'with debugging', 
the more symbols you get) and then it waits. Just type

bt

That's the backtrace. (You can type 'where'; it means the same
thing). You may have to hit return for the next page(s) of it.
Then type 

quit

to exit it. 

Before doing the gdb thing, I often type 'script', which logs
all the stuff that occurs on the screen into a file called
'typescript'. (You can type 'script some-name' and it'll log
into some-name instead). If you do this, remember to type
^D when you want to stop logging, or it'll just keep on and
on and on... Also, you'll need to use your favourite editor
on the resulting file and remove all the ^M characters from
the end of each line for readability. All the control characters,
I think, in fact. (Never use script and read a man page. Ugh.) 
This is still easier than cut-and-paste, for me, mind you :) 

If you have no corefile (sometimes they don't happen), you can
still run gdb.  Again, type 

gdb <name of program>

(without the angle brackets, yes.) You'll get the gdb copyright
notice and "reading symbols" stuff. At the prompt, type 'run'.
The program will start up. It won't start up with any arguments,
though. If you want those, you have to tell gdb about them, and
I've never tried that. Do your thing with the program until
you crash it. You'll see that gdb says something about fatal
errors or segfaults (I forget). At that stage, again, you can
type 'bt' at the gdb prompt and you'll get a backtrace.

If the program is a Gnome program, then of course you need gnome
to be working to do this last one. 

Once you've done this a few times, you get quite used to it. I
hope some of that helps someone :)

The thing I don't know is whether sending backtraces is always
helpful? If some person who understands this could answer, I'd
be grateful. I have been told in the past that often it's 
better to be able to come up with a reliable way for other people
to reproduce the crash themselves? 

Some backtraces can be huge. Really huge. And without understanding
what information is contained in it, I would have no clue whether
parts can safely be snipped out or not. Is it okay to always send
one in, or is it better just to say "I have one if you want it?"

I don't really want to overload the bug-tracking system with
unnecessary stuff (however much it looks like it from some of
my earlier attempts). But at the same time, how does someone like
me who doesn't understand the results or what's going on, balance
"as much information as possible" with "don't guess or go too
far afield; just say what you did and how someone else can do it"?

Telsa