crashes when trying to play audio as a playlist [@ two_way_short_needle | memmem | buildPlaylist]



Plugins Graveyard
8 years ago
2 years ago


(Reporter: Alex, Unassigned)




(crash signature, URL)


(1 attachment)



8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100107 Firefox/3.5.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100107 Firefox/3.5.7

Firefox 3.5.7 crashes on any attempt to play
the the text (the Greek Creed) whether one clicks
the "Click here to hear the Creed (in Greek)" or
the "speaker" icon.

(B)LFS, i686-pc-linux-gnu,, Xorg-7.5
Firefox built from: firefox-3.5.7.source.tar.bz2
RealPlayer (the "realplay")
RealPlayer (the "realplay8")

Tried both
Edit > Preferences > Applications:
  RAM file ---> Use realplay8
  RAM file ---> Use realplay

Reproducible: Always

Steps to Reproduce:
1. Go to "problem" site,
2. Click on either "Click here to hear the Creed (in Greek)" or Speaker.

Actual Results:  
Firefox crashes (disappears).

Expected Results:  
The text (Nicene Creed) to be heard recited by the speaker.

1.  After the crash, on exiting Xorg to command mode,
an "error" line can be found on the console:
<< /usr/local/lib/firefox-3.5.7/
   line 131:  1326 Segmentation fault
     "$prog" ${1+"$@"} >>

whether using realplay or realplay8.

2.  After the crash, on (re)starting Firefox,
you are hit with the "cute" oops message:
<< Well, this is embarrassing.
Firefox is having trouble recovering your window and tabs.
This is usually caused by a recently opened web page.
You can try:
 ... >>

whether using realplay or realplay8.
BTW, we're on main window, first (and only) tab.

3. If you run RealPlayer directly on the link,


everything is AOK (RealPlayer8 plays the audio)


RealPlayer10 fails with
<< The content you are trying to play uses an
 audio codec that is obsolete and no longer
 supported. ... >>

Nothing out of the ordinary.  I've seen this for
years now.  Some "ram" files are good for 8, some
are good for 10.  Fine.  Life's like that.
See the DETAILS above on how one might account for
these "idiosyncrasies".

4.  You can download the file and then try it in
"xterm", for example.  Like,
realplayx Creed.ram

You get results similar to (3) above.

5. Opera (10.10) doesn't crash (that's good).
Just sits there (that's bad).

6. Over on Windows (same hardware, different partition).
Things work as smooth as can be (and frankly, as expected).
XP SP3, IE 8, RealPlayer SP (win32) Version 1.0.1
Can you give a stacktrace?
Severity: normal → critical
Keywords: crash
Version: unspecified → 3.5 Branch

Comment 2

8 years ago
I got two strikes against me on the trace:
1. I built from sources.
2. As such, the "alternates" do no include "Beyond Linux From Scratch".

I do have one going for me:
I got the companion, xulrunner- installed (from sources :).
I understand this might help.

I'd appreciate some instructions of how to trace on a (B)LFS system.

Comment 3

8 years ago
building from sources is fine:

--enable-debugger-info-modules --disable-strip --without-stupid-vendor-options

if you haven't included anything that falls in that last class, then the first two flags are all you need to add.

Comment 4

8 years ago
Created attachment 422031 [details]
The stack trace for subject crash (540101)

Comment 5

8 years ago
> #0  0xb64e1aab in two_way_short_needle (haystack_start=0xbfffdb39, haystack_len=4294950930, needle_start=0xb09e5c5a, needle_len=7) at str-two-way.h:273
>         i = 4
>         j = 9392
>         period = 6
> #1  memmem (haystack_start=0xbfffdb39, haystack_len=4294950930, needle_start=0xb09e5c5a, needle_len=7) at memmem.c:72
>         haystack = 0xbfffdb4b ""
>         needle = <value optimized out>
> #2  0xb09d687a in buildPlaylist (instance=0xadf61000, file=0xae0b7000 "/tmp/mplayLXB9Lm", parent=0xae0b6000) at Source/plugin-list.cpp:911
>         fp = 0xa9931880
>         buffer = "", '\000' <repeats 16346 times>
>         buffer_lower = "", '\000' <repeats 16346 times>
>         url = "\000ttp://", '\000' <repeats 4058 times>

> 903 : kdekorte 	1.14 	 // simple playlist, usually old windows media
> 904 : kdekorte 	1.38 	if ((strncasecmp(buffer, "http://", 7) == 0
> 905 :   	  	|| memmem(buffer_lower, size, "http://", 7) != NULL)
> 906 :   	  	&& found == 0
> 907 :   	  	&& memmem(buffer_lower, size, "<a", 2) == NULL) {
> 908 : kdekorte 	1.1 	p = buffer;
> 909 :   	  	while (p != NULL) {
> 910 :   	  	i = size - ((long) p - (long) buffer);
> 911 :   	  	p = (char *) memmem(p, i, "http://", 7);
>                                    ^ you are here

Please file a bug against mplayerplug-in.
Last Resolved: 8 years ago
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Resolution: --- → INVALID
Summary: Firefox crashes when trying to play audio → mplayerplug-in when trying to play audio as a playlist [@ two_way_short_needle | memmem | buildPlaylist]
Version: 3.5 Branch → 1.9.1 Branch

Comment 6

8 years ago
>        p = 0xbfffdb50 ".org/creed.rm"

note that i'm not explaining why it's crashy or why they're buggy, although the fact that they sent what seems like a negative value into memmem for haystack_len does point to them doing something wrong (i don't actually see their code doing anything obviously wrong fwiw, bug i'm asleep as i write this). But roughly, this isn't crashing in our code, and it has nothing to do with us.

If you upgrade to trunk you could start using OOPP (out-of-process-plugins), but their code would still be crashy until you work with them and they fix it. :)

Comment 7

8 years ago
Hi timeless,

Thank you for your quick analysis of the situation.
> ... i'm asleep as i write this

I understand;  them Playoffs took everything out of me too :)
So now that they're over, and apologizing for the delay,
I do have some comments of my own.

> ... this isn't crashing in our code, and it has nothing
to do with us.

1.  I'm not an insider by any stretch of the imagination.
Just a regular Joe a little upset and confused that a
"latest" browser (made for browsing) is still shaky at
this day and age.
As opposed to Windows (XP) with an old (relatively) IE8
- that I suppose must do some magic of its own behind
the scenes (with plugins and what not) - which works
so effortlessly in the same situation.

In short, the talk of "they/their" and "us/our" is
100% foreign to me and frankly sounds like
"finger-pointing" to the man in the street
(the actual browser user, come to think about it).
It may have been for public consumption (as they say)
but I'm obviously caught in the middle.

2.  Be that as it may, the original plot is thicker
than one might think.

For reference, the "mplayer-plugins" are currently
 533720 2009-11-14 17:03
 533980 2009-11-14 17:03
 534020 2009-11-14 17:03
 536664 2009-11-14 17:03
 534296 2009-11-14 17:03

The irony is, if you just remove the one and only culprit,
the problem reported by me (540101) disappears like through
magic.  The audio playback starts working like a charm and
one would never know there ever was a 540101 submission,
whether "against" firefox or mplayerplugins.

This raises two issues:

3.1  Opera doesn't crash, as I mentioned.
For Firefox, that may have been a better approach after all.
At the very least, if the crash is chosen instead, a text
to the effect that "please check your plugins" should be
added to the "embarrassing" message about windows and tabs
so as to give the victim a fighting chance.

3.2.  As a more basic concept, if you accept any "foreign"
object, whether friend or foe, it should be surrounded by
code that catches errors and prevents its silently taking
down the browser.  Assertions?
I hate to start again on the Windows comparison.

Thanks again for your help.
-- Alex

Comment 8

8 years ago
So. it's very hard for me to deal with you.

First response: if you want to act like guy on the street, please use, we deal with bugs in our software. as a courtesy, and also sometimes to explain to people that it isn't our fault, we will diagnose problems caused by other software, however they are well beyond the scope of our bug tracker.

our bugs are supposed to be limited to a single issue. yours is that a certain crash occurs under certain circumstances. As such, we're only dealing with the crash, we are not interested in other things. (e.g. Why doesn't firefox ignore crashes in third party code? answer: we're working on it, but it's the subject of other bugs, and we do *NOT* need end users like you commenting in those bugs.)

fwiw I couldn't tell you the name of the library to get rid of because of the way gdb works (i could file a bug about gdb being much worse than microsoft's debugger, but I have other things to do) -- it either lists the source path info or the library name if it doesn't have debug info.

2. now that you've found the library you can take the information from this bug report and file a bug against mplayer. I can't, I don't use mplayer and if i did this for each bug filer, i'd never get any work done. We try to delegate work to the people who have time and investment. You have some of both, since you're spending time commenting here complaining about my actions.

3.1/3.2 are entirely offtopic (see earlier point about one bug per issue). Again, we're working on it, but we do not need your feedback.

The original plugin model was cooperative.

The plugin vendors were big corporations, like the browser vendors (ok both were medium corporations), plugin vendors were not supposed to crash their host. It's like you inviting me to your house and me breaking things in it, that's really rude of me, and if your wife was there she'd probably complain to me. Now, if you persist in inviting me to your house and I persist in breaking things, at some point, it's ok for your wife to complain to you and demand that you ban me from your house. We have provisions to do this too. We can ban mplayerplug-in from Firefox. If you feel that's the appropriate action, please file a bug in under

(the preceding paragraph is likely to be a follow on to the following url)

Please do report the bug url for the mplayer as a comment here. Once you've done that, we can change this bug to verified and the mplayer team being aware of their bug can work to fix it.
Summary: mplayerplug-in when trying to play audio as a playlist [@ two_way_short_needle | memmem | buildPlaylist] → crashes when trying to play audio as a playlist [@ two_way_short_needle | memmem | buildPlaylist]


8 years ago
Component: Plug-ins → Mplayer
Product: Core → Plugins
QA Contact: plugins → mplayer
Version: 1.9.1 Branch → unspecified


7 years ago
Crash Signature: [@ two_way_short_needle | memmem | buildPlaylist]


2 years ago
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.