Re: [newbie] Core dump

[John Richard Smith]

Richard Urwin wrote:

If you use:
gdb -core=core.7674 /usr/bin/mencoder
(or whereever mencoder lives on your system)
Wow,
bear with me this is all new experience for me.
so this is what I did,
[EMAIL PROTECTED] root]# cd /mnt/ext2-vol6/downloads2/divx
[EMAIL PROTECTED] divx]# ls
core.18439  core.31357  dvdripsingle  test.avi
[EMAIL PROTECTED] divx]# gdb -core=core.31357 /usr/local/bin/mencoder
GNU gdb 5.3-22mdk (Mandrake Linux)
Copyright 2002 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 "i586-mandrake-linux-gnu"...
(no debugging symbols found)...
Core was generated by `mencoder dvd://1 -ovc lavc -lavcopts 
vcodec=mpeg4:vhq:vbitrate=1024 -oac mp3lam'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libmp3lame.so.0...(no debugging symbols 
found)...
done.
Loaded symbols for /usr/lib/libmp3lame.so.0
Reading symbols from /usr/lib/libvorbis.so.0...(no debugging symbols 
found)...
done.
Loaded symbols for /usr/lib/libvorbis.so.0
Reading symbols from /usr/lib/libogg.so.0...(no debugging symbols found)...
done.
Loaded symbols for /usr/lib/libogg.so.0
Reading symbols from /usr/lib/libpng.so.3...(no debugging symbols found)...
done.
Loaded symbols for /usr/lib/libpng.so.3
Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols 
found)...
done.
Loaded symbols for /usr/lib/libjpeg.so.62
Reading symbols from /usr/lib/libfreetype.so.6...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libfreetype.so.6
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/i686/libpthread.so.0...
(no debugging symbols found)...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/i686/libm.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libc.so.6...(no debugging symbols 
found)...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x081b5fb8 in ff_combine_frame ()
(gdb)

Looks the same result to me, but I could easily be wrong.
so this "#0  0x081b5fb8 in ff_combine_frame ()"   bit , if I grasp this 
correctly, is an address refering to the original build, the source code.
[EMAIL PROTECTED] root]# mencoder -v
MEncoder dev-CVS--3.2.2 (C) 2000-2003 MPlayer Team
which is a cvs build form mplayer website, not current, I might add, but 
perhaps 3/4 months old.

you may get a little more information. It will convert the hexadecimal address 
into an address in the source code. You will be able to use this information better if you have the source code handy.

by that you mean the tar ball ?

You can use the stack backtrace commands to find which functions are active. One of which may have the bug.

You can dissassemble code around 0x081b5fb8 to find which address is triggering the segmentation fault.

I see, I don't know how to do that sound way beyond my ability as of 
this time, but I game ?

To find the bug you will need an understanding of C (or whatever else mencoder is written in,) and assembler. Otherwise the best you can do is grab a copy of the stack backtrace and mail it to the developers. The hexadecimal version isn't going to be any use to them; they need the functions names and line numbers. So use the command above, and then issue the "backtrace" command to 
gdb.

For example:
If the executable is built without debugging information you will get 

Well I just compiled in the usual way the original build, so it's not 
going to have anything special about my install.

something like:
(gdb) backtrace
#0  0x08048368 in fail ()
#1  0x0804839d in main ()
#2  0x40038c57 in __libc_start_main () from /lib/i686/libc.so.6
And if it is built with debugging information you will get something like:
(gdb) backtrace
#0  0x08048368 in fail (ptr=0x0) at segfault.c:3
#1  0x0804839d in main () at segfault.c:8
#2  0x40038c57 in __libc_start_main () from /lib/i686/libc.so.6
Without the executable you will end up with something like this:
(gdb) backtrace
#0  0x08048368 in ?? ()
#1  0xbffff3c8 in ?? ()
#2  0x0804839d in ?? ()
#3  0x40038c57 in ?? ()
 

I guess I really ought to ask for help, but ?
Have you ever tied the mplayer people , need I say more ?
Seems to me I need to ask, but in a prepared way.
It's no use just sending them the core dump, for istance, together with 
the my mencoder output ?
I know for a fact I'm not the only person with this problem, but most 
people feel intimidated by the developers.
Richard , how would you go about it ?

John

--
John Richard Smith
[EMAIL PROTECTED] 



Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com