On Saturday 03 Jan 2004 6:44 pm, John Richard Smith wrote: > #0 0x081b5fb8 in ff_combine_frame () > (gdb) > ------------------------------------------------------------------- > later > ===== > I should of read your email more carefully > > #0 0x081b5fb8 in ff_combine_frame () > (gdb) backtrace > #0 0x081b5fb8 in ff_combine_frame () = hexadecimal address ? > #1 0x40d5df40 in ?? () = source code address ?
The problem occurred at address 0x81b5fb8 which is in function ff_combine_frame. There is no other valid address on the stack, which means that either the bug wrote rubbish over the stack, or ff_combine_frame is the top level of a thread. > (gdb) > > which makes more sense. But how do I use it ? > I mean what do I do next ? Unless you want to debug the C yourself, nothing. I would do nothing with this version, I'd get the latest first. > > ------------------------------------------------------------------ > [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. Your first job then is to upgrade it. It might be a bug that is already fixed. It is also easier for people to find if the information you give relates to the code they have available. Otherwise they're only going to ask you to run the current version. > >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 ? Yes, but it's only worthwhile if you want to look through the C source code yourself. > > >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 ? That's a steep learning curve. The Pentium datasheet is a book 2 inches thick. > 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 ? They are normally really nice people. The best way to go about it is to 1. Read all the documentation and install the latest CVS version. http://www.MPlayerHQ.hu/homepage/design6/info.html#docs says: "Sending bugreports First try the development (CVS) version too, maybe your bug is already known and fixed, but the new version hasn't been released. Please read all the docs in the package, most common problems and possible workarounds are described somewhere. We will NOT answer questions which are already answered in the documentation! If you couldn't solve the problem, then send us a quality bugreport: read the bugreporting section for details!" The bug reporting section is at http://www.MPlayerHQ.hu/DOCS/HTML/en/bugreports.html 2. Generate the crash in gdb as detailed in the above URL and grab all output. 3. Subscribe to the mplayer-users mailing list. Listen for a day or two and/or read the archives to get a hang of the etiquette. 4. Post a full description of the problem together with the gdb output and the version numbers of everything that may make a difference, especially your Linux distribution, kernel build and mencoder version. Offer to post the file that causes the problem, (I imagine it's a bit large for a public mailing list.) It's probably a good idea to mention any mencoder versions that you have seen to fail. -- Richard Urwin
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
