gaim/www
Clone
Summary
Browse
Changes
Graph
Initial import into CVS
chipx86
start
2002-09-26, Christian Hammond
2b210e25fed4
Initial import into CVS
<?php
require
"html.inc.php"
;
start_html
(
"GDB Help"
);
start_section
(
"How To Make Use Of A Core File"
);
?>
<p>
So
Gaim
crashed
on
you
again,
huh?
I'm
sorry
to
hear
that.
Maybe
you
can
help
prevent
it
from
happening
again.
</p>
<p>
When
a
program
crashes
it
typically
leaves
a
core
file
behind.
In
a
console
window
when
you
run
<code>
ls
</code>
,
you
should
see
a
file
called
<code>
core
</code>
:
</p>
<p><code>
~
$
<b>
ls
</b><br
/>
core
</code></p>
<p>
Sometimes
this
file
is
also
called
gaim.core
or
something
similar,
depending
on
what
OS
you
use
and
what
your
settings
are.
If
you
don't
see
this
file,
it's
possible
that
it's
in
a
different
location,
and
you
should
look
at
the
settings
for
your
OS
to
see
where
it
might
be.
It's
also
possible
that
the
core
file
was
not
created
at
all;
this
would
happen
if
your
system
was
configured
not
to
leave
a
core
file.
</p>
<p>
If
you
have
a
core
file,
first
check
to
make
sure
that
it
was
created
by
gaim,
by
using
<code>
file
</code>
to
examine
it:
</p>
<p><code>
~
$
<b>
file
core
</b><br
/>
core:
ELF
32-bit
LSB
core
file
of
'gaim'
(signal
11),
Intel
80386,
version
1,
from
'gaim'
</code></p>
<p>
The
output
of
<code>
file
</code>
may
look
different
depending
on
your
OS
and
hardware,
but
it
should
still
be
apparent
that
it
was
created
by
gaim.
</p>
<p>
Now
that
you
have
the
core
file,
you'll
want
to
get
the
useful
information
out
of
it.
In
order
to
do
that,
you'll
have
to
open
it
in
GDB.
GDB
stands
for
GNU
DeBugger,
and
is
a
very
useful
programmer's
tool.
It
needs
to
know
which
application
created
the
core
file
and
what
the
core
file
name
is,
so
run:
</p>
<p><code>
~
$
<b>
gdb
gaim
core
</b></code></p>
<p>
If
you
use
the
applet
version
of
gaim,
you
should
use
<code>
gaim_applet
</code>
instead
of
<code>
gaim
</code>
when
running
<code>
gdb
</code>
.
You
don't
have
to
give
the
full
path
to
the
<code>
gaim
</code>
/
<code>
gaim_applet
</code>
binary
as
long
as
it
is
in
your
PATH
environment
variable
(i.e.
if
you
can
run
<code>
gaim
</code>
and
have
it
work,
you
don't
need
the
full
path).
You
do,
however,
have
to
specify
the
correct
name
of
the
core
file.
At
this
point,
gdb
should
start
printing
information
about
what
it's
doing:
</p>
<pre>
GNU
gdb
5.0
Copyright
2000
Free
Software
Foundation,
Inc.
GDB
is
free
software,
covered
by
the
GNU
General
Public
License,
and
you
are
welcome
to
change
it
and/or
distribute
copies
of
it
under
certain
conditions.
Type
"show
copying"
to
see
the
conditions.
There
is
absolutely
no
warranty
for
GDB.
Type
"show
warranty"
for
details.
This
GDB
was
configured
as
"i686-pc-linux-gnu"...
Core
was
generated
by
`gaim'.
Program
terminated
with
signal
11,
Segmentation
fault.
Reading
symbols
from
/usr/lib/libesd.so.0...done.
Loaded
symbols
for
/usr/lib/libesd.so.0
Reading
symbols
from
/lib/libm.so.6...done.
Loaded
symbols
for
/lib/libm.so.6
</pre>
<p>
And
so
forth.
There
are
a
couple
reasons
why
you
might
see
something
other
than
this.
One
reason
is
if
gdb
can't
find
something
it
needs,
it
might
give
a
warning
such
as
<code>
"No
such
file
or
directory."
</code>
,
in
which
case
you
may
have
to
give
the
full
path
to
both
gaim
and
the
core
file.
Another
reason
would
be
if
the
core
file
isn't
created
by
gaim,
you
may
see
a
message
saying
"warning:
core
file
may
not
match
specified
executable
file."
</p>
<p>
If
gdb
loaded
gaim
and
the
core
file
successfully,
then
once
it's
done
loading
all
the
symbols
that
it
will
need,
it
should
print
the
information
from
the
top
of
the
stack,
and
prompt
you:
</p>
<pre>
#0
0x404f1140
in
poll
()
from
/lib/libc.so.6
(gdb)
</pre>
<p>
Now
you'll
want
to
get
the
backtrace.
At
the
prompt,
type
either
<code>
backtrace
</code>
or
<code>
bt
</code>
.
gdb
should
then
print
a
list
of
all
the
functions
that
were
called
leading
up
to
the
crash:
</p>
<pre>
(gdb)
<b>
backtrace
</b>
#0
0x404f1140
in
poll
()
from
/lib/libc.so.6
#1
0x40325f99
in
g_main_poll
(timeout=-1,
use_priority=0,
priority=0)
at
gmain.c:1034
#2
0x4032594d
in
g_main_iterate
(block=1,
dispatch=1)
at
gmain.c:808
#3
0x40325cfc
in
g_main_run
(loop=0x81becb0)
at
gmain.c:935
#4
0x4023b4b7
in
gtk_main
()
at
gtkmain.c:524
#5
0x805b131
in
main
(argc=1,
argv=0xbffffa94)
at
aim.c:669
#6
0x4044938b
in
__libc_start_main
()
from
/lib/libc.so.6
(gdb)
</pre>
<p>
When
you
get
the
backtrace,
instead
of
seeing
function
names,
you
might
see
'??'
instead.
If
that's
the
case,
gdb
couldn't
read
the
function
names
from
gaim
and
the
core
file,
and
so
the
core
file
won't
end
up
being
very
useful
after
all.
However,
if
you
were
able
to
see
the
function
names,
then
copy
all
of
the
output
from
the
backtrace
and
post
a
<a
href=
"bug.php3"
>
bug
report
</a>
.
Be
sure
to
also
indicate
what
you
were
doing
at
the
time.
</p>
<p>
Now
you
can
exit
gdb
by
typing
<code>
quit
</code>
:
</p>
<p><code>
(gdb)
<b>
quit
</b><br
/>
~
$
</code></p>
<p>
There
may
be
other
useful
information
that
can
be
retrieved
from
the
core
file,
such
as
the
values
of
variables.
For
this
reason
it's
a
good
idea
to
keep
the
core
file.
If
you
upgrade
Gaim,
the
core
file
will
no
longer
match
the
binary,
and
it
won't
be
useful
anymore;
however,
don't
let
that
stop
you
from
upgrading
Gaim,
since
there's
a
good
chance
your
bug
will
have
been
fixed.
</p>
<?php
end_section
();
end_html
();
?>