[MPlayer-users] Segfault core dump over innocently missing GLX

[Robert Bradbury]

On 8/5/07, Guillaume POIRIER <poirierg at gmail.com> wrote:

> This bug report is worthless, you need to have MPlayer compiled with
> debug symbols if you wanna have a readable backtrace.
>

Yes, but *most* people working with "public" Linux distributions don't even
have the source, much less binaries compiled with debug symbols.  I took the
trouble to compile mplayer with debug symbols and my binary ended up being
118 MB.  I have also have some video/audio streams which I've used it on and
the stack traces reveal just as little information as the one from
debcoder.  I presume this is probably because the fault is in some plugin
library which doesn't happen to be compiled with debug symbols.  A quick
check reveals that an mplayer playing an mp3 has 73 shared libraries linked
into the address space.  Most of those are *not* part of mplayer but are
instead system libraries linked in with it.  So one not only has to find,
download and build a "debug" mplayer but one also has to do that with a
non-trivial number of system libraries as well.  Given my experience over
the last year with Firefox I'd say this would probably take at least several
days perhaps as much as a week.

If you really want people to provide *good* bug reports the mplayer
developers need to provide a binary with debug symobls which is relatively
static (no shared libraries) which is downloadable for the common
architectures! [1]. Then at least users have a quick way to test a known
debug ready version against their test case and can split the problem into
"my version of mplayer & OS" vs. "its a real deficiency in the source".

I believe I have run across discussions that there is a way to compile C
programs with debug symbols being kept in a separate file (but I don't know
how one does this [2]).  I may have also seen some suggestions that Ubuntu
is going to be moving towards a system where there is an optional part of
the package which contains the debug symbols.  Given the case above the
second part of debugging on the user's part would be to install the mplayer
debug symbol package and reproduce the stack trace using it.  However even
if this were available for Ubuntu it would be questionable whether other
Linux users could use it.

It would help significantly if the mplayer developers would setup
configuration options which produced this type of system (a *static* binary
and/or debug symbols in a separate file [3]).  Then it could be incorporated
into all Linux distributions.

1. I'll note that the Mozilla/Firefox developers should be providing a
similar package as well but they too fail to understand what it will take to
get good bug reports from users back to developers.
2. If anyone does know how to do this please share the information!
3. It should be the case that the classical "-debug" and "-static" configure
options should do this but I've found in many packages they don't
exist/work.  I for one would setup a shadow disk which contained the static
and/or debug symbol files for most of the more complex packages on my system
allowing me to produce normal system disk binary copies but still easily
debug things when I had to do so.  One could even setup NFS access to the
debug "bin" and "lib" directories -- or the mplayer developers could do
this...