On 6/17/06, Mike Hommey <[EMAIL PROTECTED]> wrote:
Finally got a valid backtrace on this with your suggestion this evening.
I've also instructed the other users on how to start it up properly and they
will continue with attempts to gather more debug information.
We have more detailed information about what appears to be causing
the crash and its behavior leading up to and after the crash. We did a
clean install of firefox 1.5.0.4 off the mozilla website with no plugins at
all. This was installed separately under /usr/local so as not to interfere
with the debian package. That version ran stable for over 3 days. No
crashes at all. We then installed the mplayer plugin built from source
using the most recent version of MPlayer directly off the mplayer site
and the latest version of mplayerplug-in from the sourceforge site. We
now see that when we get a popup that displays a small alert message
and plays a .wav file using an embed tag (shown below), most times
the browser will crash.
{embed autostart="true" hidden="true" src="" loop="5"}
Checking the "about:plugins" page indicates that .wav files are being
handled by mplayerplug-in-wmp.so. Another odd thing is that after the
crash, when firefox is restarted, it will present the same dialog box that
normally gets presented when you exit by clicking the "Quit" entry in the
"File" menu, asking you if you wish to clear your private information.
I'm CCing this note to the debian bugzilla bug # 306537 which is the
one that currently seems to match best. If anyone can suggest a more
appropriate bug to move the details to, I'll be happy to do so. The thing
I'm primarily concerned about is what sort of visibility this has. Are the
mozilla/firefox developers accutely aware of these stability issues? I
can't believe we are the only people on the planet having this problem;
lots of people have to be viewing pages with embedded sound files;
the problem *MUST* be affecting them as well. We're not doing any
thing special. What's the level of interest in finding and stamping out
these problems? Are they backburnered or are they being actively
pursued. We're trying to provide any feedback we can, and will
continue to do so. In the mean time, since the instability seems to be
related to the mplayer plugin, can anyone suggest a stable alternative
to provide for playing of .wav or other standard sound files from inside
our alert popups? Something like mozplugger/xmms or such, but a
solution *known* to be ROCK SOLID?
thanks,
Jim
On Sat, Jun 17, 2006 at 10:27:21AM -0400, Jim Wiggs <[EMAIL PROTECTED]> wrote:
> Gentlemen,
>
> I've downloaded and installed firefox-dbg attempting to produce
> useful stacktrace information WRT bug #306537. Starting firefox
> with the -debug option still does not produce useful output upon
> crash (generic error, no symbol information). How do I actually
> get gdb to *use* the symbol information supposedly provided by
> the firefox-dbg package? The package appears to contain no
> documentation about how to actually use it. There's a firefox-bin
> file installed under /usr/lib/debug/usr/lib/firefox but invoking it
> directly within gdb produces an immediate error:
You just need to run firefox -debug. Are you sure you get an actual
crash ? It could be that something triggers a shutdown of firefox, which
then exits normally.
If you want to be sure firefox -debug just works, run it, launch firefox
with run, find out the pid, and kill -11 it. Then you'll be able to get
a full backtrace.
Finally got a valid backtrace on this with your suggestion this evening.
I've also instructed the other users on how to start it up properly and they
will continue with attempts to gather more debug information.
We have more detailed information about what appears to be causing
the crash and its behavior leading up to and after the crash. We did a
clean install of firefox 1.5.0.4 off the mozilla website with no plugins at
all. This was installed separately under /usr/local so as not to interfere
with the debian package. That version ran stable for over 3 days. No
crashes at all. We then installed the mplayer plugin built from source
using the most recent version of MPlayer directly off the mplayer site
and the latest version of mplayerplug-in from the sourceforge site. We
now see that when we get a popup that displays a small alert message
and plays a .wav file using an embed tag (shown below), most times
the browser will crash.
{embed autostart="true" hidden="true" src="" loop="5"}
Checking the "about:plugins" page indicates that .wav files are being
handled by mplayerplug-in-wmp.so. Another odd thing is that after the
crash, when firefox is restarted, it will present the same dialog box that
normally gets presented when you exit by clicking the "Quit" entry in the
"File" menu, asking you if you wish to clear your private information.
I'm CCing this note to the debian bugzilla bug # 306537 which is the
one that currently seems to match best. If anyone can suggest a more
appropriate bug to move the details to, I'll be happy to do so. The thing
I'm primarily concerned about is what sort of visibility this has. Are the
mozilla/firefox developers accutely aware of these stability issues? I
can't believe we are the only people on the planet having this problem;
lots of people have to be viewing pages with embedded sound files;
the problem *MUST* be affecting them as well. We're not doing any
thing special. What's the level of interest in finding and stamping out
these problems? Are they backburnered or are they being actively
pursued. We're trying to provide any feedback we can, and will
continue to do so. In the mean time, since the instability seems to be
related to the mplayer plugin, can anyone suggest a stable alternative
to provide for playing of .wav or other standard sound files from inside
our alert popups? Something like mozplugger/xmms or such, but a
solution *known* to be ROCK SOLID?
thanks,
Jim
