Closed Bug 267926 Opened 20 years ago Closed 20 years ago

mplayer plugin crash [@ buildPlaylist]

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mozilla, Assigned: bugzilla)

Details

(Keywords: crash)

Crash Data

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041012 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041012 Firefox/0.10.1

/usr/bin/firefox: line 392:  1920 Segmentation fault      $mozbin "$@"

I'm getting this a lot - leaving Firefox open in crashes every day or two. The
most recent time it was while typing into a text field on a form. Several of the
other times have also been while making entries on form.

Reproducible: Sometimes
Steps to Reproduce:
1. Start firefox
2. Use for a day or two
3. Wait for crash

Actual Results:  
Crash!


This is a Gentoo ebuild. The current theme is Plastifox Crystal, but it was
happening with other themes too. 

(With so many different segfault reports in bugzilla, Firefox's versioning is a
bit exuberant. Rather that version 1 preview, this should be like version 0.35
alpha.)
I'm getting this too, I just got 28302 rather than 1920.
Gentoo + Plastikfox Crystal, also.
I don't know if this is any help, but it segfaulted, same line number, while
selecting multiple bookmarks from the bookmark manager, while holding down ctrl.
/usr/bin/firefox: line 392: 13568 Killed                  $mozbin "$@"

Firefox crashes, occasionally, just as it's loading.  This happens seemingly
randomly.  It happens nearly every time that I start Firefox after a clean boot,
or if I havn't used the browser for a lengthy stretch of time.

I'm running an up-to-date install of Gentoo (and gnome) and this has been
happening since install 2 weeks ago.

Firefox very rarely crashes while I'm using it, unlike the other bug-reporters,
though I don't leave the browser running for extended lengths of time.
I should have mentioned that I emerged firefox using the mozilla-firefox-bin
rather than building from the source


(In reply to comment #3)
> /usr/bin/firefox: line 392: 13568 Killed                  $mozbin "$@"
> 
> Firefox crashes, occasionally, just as it's loading.  This happens seemingly
> randomly.  It happens nearly every time that I start Firefox after a clean boot,
> or if I havn't used the browser for a lengthy stretch of time.
> 
> I'm running an up-to-date install of Gentoo (and gnome) and this has been
> happening since install 2 weeks ago.
> 
> Firefox very rarely crashes while I'm using it, unlike the other bug-reporters,
> though I don't leave the browser running for extended lengths of time.


that's nice, now just emerge something to make it debuggable.

./mozilla -g -d gdb
run
(when it crashes)
where

attach the stack trace
(In reply to comment #5)
> that's nice, now just emerge something to make it debuggable.
> 
> ./mozilla -g -d gdb
> run
> (when it crashes)
> where
> 
> attach the stack trace

The stack trace will be onscreen at that point? If not, let me know where to
fetch it from. I'll try to get that for you. 
May be more than a few days since Firefox is crashing for different reasons each
usually a few days apart. The last three leaving as their last messages:

1. (firefox-bin:370): Gdk-CRITICAL **: file gdkwindow-x11.c: line 1279
(gdk_window_show): assertion `GDK_IS_WINDOW (window)' failed

2. (firefox-bin:370): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_unref): assertion `G_IS_OBJECT (object)' failed

- Both also had other critical warnings before those. And most recently:

3. (firefox-bin:370): Gdk-WARNING **: GdkWindow 0x30c5e28 unexpectedly destroyed
/usr/bin/firefox: line 392:   370 Segmentation fault      $mozbin "$@"
(In reply to comment #5)
> that's nice, now just emerge something to make it debuggable.
> 
> ./mozilla -g -d gdb

Um, you do mean "firefox -g -d gdb" right?

And by "emerge" you don't mean actually emerging any additional package, right,
since you don't mention one?
(In reply to comment #7)

> Um, you do mean "firefox -g -d gdb" right?

After googling around: Looks like you mean Firefox needs to be re-emerged with
debugging symbols included, and then run with gdb.

Can you please either give full instructions or refer us to somewhere where the
full instructions are documented? Sometimes people are as bad at understanding
vague instructions as computers are, especially those of us who don't already
have experience with gdb.

Also, as a note, my Firefox version is now 1, not the preview, and this bug is
still, of course, there.
full instructions for what? emerge? that's someone else's problem. gdb? that's
someone else's program. i gave you sufficient instructions (minus using
./mozilla instead of ./firefox, but you clearly figured that part out on your
own). you're welcome to read http://www.mozilla.org/unix/debugging-faq.html if
you feel like it.
(In reply to comment #9)
> full instructions for what? emerge? that's someone else's problem. gdb? that's
> someone else's program. i gave you sufficient instructions (minus using
> ./mozilla instead of ./firefox, but you clearly figured that part out on your
> own). you're welcome to read http://www.mozilla.org/unix/debugging-faq.html if
> you feel like it.

These instructions are not clear:

> ./mozilla -g -d gdb
> run
> (when it crashes)
> where
> 
> attach the stack trace

First, what directory are you in for the ./ start?

Second, if I run that command as "firefox -g -d gdb" (that is, don't make it
directory dependent) I never get to the gdb interface, firefox just starts up.
So the "run" line isn't applicable. It also appears to make the system unstable,
even outside of firefox - delays in accepting typing into xterms and the like.
It should be expected to do that?

Anyway, /usr/bin/firefox is a symlink of course to /usr/libexec/mozilla-launcher
- so it's not like there's a different "firefox" that'll start according to
whether I'm in a specific directory and start it as ./firefox rather than
firefox, right (since prepending ./ means "start the instance in this directory
rather than in the path")?

Are you presuming that I'm running some other version or installation than the
Gentoo ebuild of Firefox 1.0? Because otherwise your instructions don't work as
given. Please test them on a Gentoo box yourself before insisting that your
instructions are complete and correct. 
(In reply to comment #9)
> you're welcome to read http://www.mozilla.org/unix/debugging-faq.html if
> you feel like it.

Read that. The plain "firefox -g" that it recommends doesn't work either.
However the more standard "gdb firefox-bin" does work, except as gdb notes there
are no debugging symbols found:

This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)...
(gdb) run
Starting program: /usr/lib/MozillaFirefox/firefox-bin 
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...
(no debugging symbols found)...(no debugging symbols found)...[New Thread 16384
(LWP 8127)]

So will this even produce results worthwhile to you, or do I need to re-emerge
Firefox with debugging symbols (by what command?) in order to get you the data
you need to fix this segfault bug?

Also, since you've had other reports confirming this bug, please escallate it
from "Unconfirmed."

Okay, here's a crash from you (via "gdb firefox-bin"):

MMX2 supported but disabled
SSE supported but disabled
3DNow supported but disabled
3DNowExt supported but disabled
Can't open '/root/.mplayer/codecs.conf': No such file or directory
Can't open input config file /root/.mplayer/input.conf: No such file or
directory
Option stream url: This URL doesn't have a hostname part.
File not found:
'caskets.wav...........................................................................................................
Failed to open
http://www.funeraldepot.com/caskets.wav................................................................................
firefox-bin: stack smashing attack in function buildPlaylist()

Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 8127)]
0x409cd811 in kill () from /lib/libc.so.6
(gdb) 
(gdb) where
#0  0x409cd811 in kill () from /lib/libc.so.6
#1  0x409b968f in __stack_smash_handler () from /lib/libc.so.6
#2  0x426e2db1 in ?? ()
(gdb) 

There is, by the way, a /usr/share/mplayer/codecs.conf and input.conf. The
"stack smashing attack" report is probably a result of building with
"-fstack-protector" - although I was seeing crashes in a previous version built
without (my original report here). This wasn't in this case a total crash -
Firefox remained running but was inaccessible - wouldn't display when going back
to it from another screen - had to kill. So this may be one of the many other
crashes I've been seeing, and not the seg fault one - I'm assuming there are
multiple bugs here not just one.

(As for fumeraldepot.com - a side track from a site about trees. Yargh.)
http://article.gmane.org/gmane.comp.mozilla.mplayerplug-in/257
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Keywords: crash
Resolution: --- → INVALID
Summary: Segmentation fault - line 392 → mplayer plugin crash [@ buildPlaylist]
Crash Signature: [@ buildPlaylist]
You need to log in before you can comment on or make changes to this bug.