Closed Bug 775095 Opened 8 years ago Closed 7 years ago

Hovering over Flash content crashes whole browser

Categories

(Core :: JavaScript Engine, defect, critical)

14 Branch
x86
All
defect
Not set
critical

Tracking

()

RESOLVED INVALID
Tracking Status
firefox15 - ---
firefox16 - ---

People

(Reporter: galtgendo, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, Whiteboard: [js:waitingforinfo])

Crash Data

Attachments

(7 files)

Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1
I suspected that this was a problem with just Adobe flash plugin as I'm usually forced to use 10.3 on this machine (no sse2), but I've tested it with the version pulled from chrome 19 (10.2.202.236) and the crash is still reproducible.

This report comes from 14.0.1, but the crashes happened since at least 13.0.

This site (http://www.avonpolska.pl/ebrochure/ebrochure.html) is more or less an overgrown pdf viewer, but shortly after it loads, it crashes the whole browser.
There are quite a few flash sites acting this way (not youtube though), but this one seems to be most easy to access.

If it were only plugin crashing, it wouldn't be a big deal, but not if the whole browser goes down.

Seems to be somehow related to mouse activity, as the crashes seems to happen as I move the mouse over the flash element.
Could post some crash reports links, please? (type about:crashes)
(In reply to Loic from comment #1)
> Could post some crash reports links, please? (type about:crashes)

...there are none.

--enable-application=browser --enable-optimize=-O2 --with-system-jpeg --with-system-zlib --enable-pango --enable-svg --enable-system-cairo --disable-installer --disable-pedantic --disable-updater --disable-strip --disable-strip-libs --disable-install-strip --enable-single-profile --disable-profilesharing --disable-profilelocking --enable-elf-dynstr-gc --enable-default-toolkit=cairo-gtk2 --enable-official-branding --enable-ogg --enable-wave --enable-dbus --disable-debug --disable-tests --disable-debugger-info-modules --enable-ipc --enable-libnotify --enable-startup-notification --enable-system-sqlite --with-sqlite-prefix=/usr --disable-necko-wifi --enable-webm --with-system-libvpx --enable-tracejit --with-system-nspr --with-nspr-prefix=/usr --with-system-nss --with-nss-prefix=/usr --x-includes=/usr/include --x-libraries=/usr/lib --with-system-libevent=/usr --enable-system-hunspell --disable-gnomevfs --disable-gnomeui --enable-gio --enable-storage --enable-places --enable-places_bookmarks --enable-oji --enable-mathml --disable-mochitest --prefix=/usr --libdir=/usr/lib --disable-gconf --disable-mailnews --enable-canvas --enable-safe-browsing --with-system-png --enable-system-ffi --with-default-mozilla-five-home=/usr/lib/firefox --target=i686-pc-linux-gnu --enable-gstreamer --enable-system-sqlite --enable-methodjit --enable-tracejit --enable-extensions=default

(that's obviously 14.0)

crashreporter is disabled as the maintainer claims symbols would disagree anyway.
Does it happen with Flash 11.2.202.236?
Does it happen with a new profile (see https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles)?
Can you attach a stack trace (see https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report#Linux)?
Attached file unusable stack trace
Sorry, but the only stack trace I can provide is an unusable one.

A non-debug build of firefox 14.0 took about three and a half hours.
I have doubts if this machine still has enough memory for a debug build and its speed penalty is prohibitive.

As for Flash 11.2.202.236, I already said that's the exact version from chrome 19 (at least the strings in the lib suggest that) - the one from Adobe is unusable due to using sse2.

I'm nearly sure the crash is triggered by mouse entering the flash object, as till it does the object is displayed properly (and I can even scroll the page).
It's odd that Firefox crashes if OOPP is enabled. Please try the new profile.
Severity: normal → critical
Keywords: crash
Well, so... a new profile...
The result makes no sense.
With Flash 11.2 the result was a SIGILL:
i686-pc-linux-gnu-gcc 	gcc version 4.5.4 (Gentoo 4.5.4 p1.0, pie-0.4.7) 	-Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wno-unused -Wno-overlength-strings -Wcast-align -march=athlon -mtune=athlon -pipe -mno-avx -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -O2 -fomit-frame-pointer
i686-pc-linux-gnu-g++ 	gcc version 4.5.4 (Gentoo 4.5.4 p1.0, pie-0.4.7) 	-fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -march=athlon -mtune=athlon -pipe -mno-avx -fno-exceptions -fno-strict-aliasing -std=gnu++0x -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -O2 -fomit-frame-pointer 

This processor *is* an athlonxp and it would seem signal happens in firefox not in the plugin.

With Flash 10.3, it's SIGTRAP followed by SIGSEGV...
huh...?
Component: General → Plug-ins
Product: Firefox → Core
Just a little detail - the whole page loads and seems to fully work, but the moment I try to switch to a different tab (even if it's only about:plugins), the browser crashes.
It seems that under certain specific circumstances even youtube can crash the browser (though my combination of AdBlock Plus/Flash Bock could have played a role too).

Just after that youtube page has crashed the browser, I've used opera to recheck it.
The first thing that was played was an advertisement - after watching that (and the clip), I've restarted firefox and this time there was no advertisement and no crash.

There seems to be a pattern here (changing focus, unloading...?).
Unfortunately, without a stack trace, nothing can be done. Try to install Nightly to get one: http://nightly.mozilla.org/.
(In reply to Scoobidiver from comment #9)
> Unfortunately, without a stack trace, nothing can be done. Try to install
> Nightly to get one: http://nightly.mozilla.org/.

How about a little modification:
is there a build of 14.0 with debug symbols available for download ?
if so, how do I run it so it doesn't mess up my ${HOME}/.mozilla/firefox ?

(well, technically, I could create a new user, but I'd consider any result from that way highly unreliable)
Only Nightly builds have debug symbols.
Use a new profile to test: see http://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles
OK, I just hope '-no-remote' and a new profile was enough to preserve my settings.

Fortunately, http://crash-stats.mozilla.com/report/index/bp-fc51f177-bbad-4210-96b7-b421f2120719.
(In reply to Rafał Mużyło from comment #13)
> http://crash-stats.mozilla.com/report/index/bp-fc51f177-bbad-4210-96b7-
> b421f2120719.
As said before, this stack trace has no symbols.
Is there something besides main archive that I should download from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-release-linux-debug/1342218862/ then ?
OK, a better question: is the thing I should download firefox-14.0.1.en-US.linux-i686.crashreporter-symbols.zip and if so, how do I use it ?
So, the answer was no (there's other stuff in that archive).
Though the other interesting question is "why were those *debug* builds stripped in the first place ?".
Debug builds are not stripped, the thing you install contains the symbols. But we don't upload those symbols to crash-stats.mozilla.com because if you have a debug builds, you presumably want to debug it locally and not send in release crash reports. So there is pretty much nothing we can do with that old crash report now; you'd have to either use a release build to get good stacks in the future, or attach a debugger to your debug build.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #18)
> Debug builds are not stripped, the thing you install contains the symbols.
> But we don't upload those symbols to crash-stats.mozilla.com because if you
> have a debug builds, you presumably want to debug it locally and not send in
> release crash reports. So there is pretty much nothing we can do with that
> old crash report now; you'd have to either use a release build to get good
> stacks in the future, or attach a debugger to your debug build.

Are you talking about debug spew that those debug builds *do* produce or gdb symbols that are obviously missing ?
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Every single -debug from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ that I've tried was the same - stripped.
In case those error reports don't include anything again, 'thread apply all bt full' for 17.0a1.
Assignee: nobody → general
Blocks: 682573
Status: UNCONFIRMED → NEW
Crash Signature: [@ js::Interpret(JSContext*, js::StackFrame*, js::InterpMode)] [@ js::Interpret ]
Component: Plug-ins → JavaScript Engine
Ever confirmed: true
Summary: flash plugin crashes whole browser → Hovering over Flash content crashes whole browser
Version: 14 Branch → Trunk
"hovering over Flash content" is a bit imprecise.
With all of my extensions (AdBlock Plus/Flash Block + one or two like them) it's entering the object.
With a new profile - switching to a different tab.
So focus does seem to play a role, but it's most likely closer to context changes (perhaps plugins unload ?).
Component: JavaScript Engine → Plug-ins
Version: Trunk → 14 Branch
Sorry, browser didn't refresh all the fields (again).
Component: Plug-ins → JavaScript Engine
Version: 14 Branch → Trunk
On a semi-related note: perhaps it would be a good idea if those -debug builds were *not* stripped.
Whiteboard: [js:waitingforinfo]
Any info I could try to provide or is it simply waiting for someone on javascript team to find time to look at ?
Minor note: I've just went through mozilla-central builds - it seems this particular crash was fixed from 22.07 to 23.07.

Seems that it was exchanges by a couple others, including one that somehow bypasses crashreporter.

Now lets see if I can find the commit in question (I said it a few times already - mercurial web interface sucks compared to git).
It seems to be fixed in aurora on the same date - still no closer to the particular commit.
Correction in regard of aurora - it's actually 20.07 to 21.07 - that would strongly hint at 5527cad88327 + cb9481958a96.

I'll try to test during weekend.
...never mind - while I'm about sure in regard of the commits, they just revert code to the state in 14.0.1. So it's just a side effect of a different fix.
OK, I did more crash testing with today's nightly debug data (which still crashes).

Might be related:
as the page loads, last debug message is
WARNING: OpenGL-accelerated layers are not supported on this system.: file ../../../widget/xpwidgets/nsBaseWidget.cpp, line 848

The crash happens upon switching to a different tab, but there seems to be an additional prerequisite.

If I let the page load and won't click anywhere on the flash object, I can switch the tab without a crash. Also, just *hovering* over the object (as opposed to the current bug description) doesn't trigger the crash. But if I click an active element (or so it would seem) of the object, a tab switch immediately triggers the crash.
For a change:
http://crash-stats.mozilla.com/report/index/bp-37efbfd5-302c-42c9-8345-416402120728

As the data likely says, this is from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-linux/1343432977/firefox-15.0.en-US.linux-i686.tar.bz2

That one is not striped, so it might be helpful, if there's still will to hunt this down for firefox 15.
...correction of comment 31: ...more crash testing with today's nightly debug *beta*...
To quote session manager: "well, this is embarrassing".

It's not fixed in aurora nor trunk after all, I was simply being lucky in my initial tests.

While reproducing the crash is quite easy, it seems to rely on some random factor - sometimes I get a few good restarts in a row, sometimes it crashes the whole time.
I tried to repro in a Beta build, but I couldn't. I'm not sure I'm doing it right. I did this:

1. Start a session with the linked URL in the first tab and yahoo.com in the second tab.
2. Click on the plugin area (the catalog)
3. Click on the other tab.
(In reply to David Mandelin [:dmandelin] from comment #35)
> I tried to repro in a Beta build, but I couldn't. I'm not sure I'm doing it
> right. I did this:
> 
> 1. Start a session with the linked URL in the first tab and yahoo.com in the
> second tab.
> 2. Click on the plugin area (the catalog)
> 3. Click on the other tab.

Close.

While I had the crash with many activities, the one most likely to trigger it would be:
2. Click on the plugin area (the catalog), so that its page is gets flipped.

Of course, there's still a chance, it's x86 (or even no-sse2) limited.
(In reply to Rafał Mużyło from comment #36)
> (In reply to David Mandelin [:dmandelin] from comment #35)
> > I tried to repro in a Beta build, but I couldn't. I'm not sure I'm doing it
> > right. I did this:
> > 
> > 1. Start a session with the linked URL in the first tab and yahoo.com in the
> > second tab.
> > 2. Click on the plugin area (the catalog)
> > 3. Click on the other tab.
> 
> Close.
> 
> While I had the crash with many activities, the one most likely to trigger
> it would be:
> 2. Click on the plugin area (the catalog), so that its page is gets flipped.
> 
> Of course, there's still a chance, it's x86 (or even no-sse2) limited.

I just tried about 6 times and didn't get the crash. I did actually get a freeze on close in one of my trials yesterday. 

It looks like it's going to be pretty difficult to move forward on this bug from here. If you could generate a stack trace of the crash that had signatures, we might be able to spot something. But even with just the signatures, we might not be able to figure anything out.
Well, this x86 machine is quite old and its video card is even doubly so, so it just might be some kind of a corner case.

What do you mean by "a stack trace of the crash that had signatures" ?
Something more than "thread apply all bt full" on the not stripped non-debug builds ?

As I said, -debug ones are stripped and there didn't seem to be anything of notice among the final debug messages (those few following "WARNING: OpenGL-accelerated layers") anyway.
(In reply to Rafał Mużyło from comment #38)
> Well, this x86 machine is quite old and its video card is even doubly so, so
> it just might be some kind of a corner case.
> 
> What do you mean by "a stack trace of the crash that had signatures" ?
> Something more than "thread apply all bt full" on the not stripped non-debug
> builds ?

Like this one:

https://crash-stats.mozilla.com/report/index/1f20148e-2dd6-4050-a840-667592120730

where you can see the names of the functions in the stack trace. I guess something about your Gentoo builds strips out the symbols?
Well, if you're talking about *system* libs being stripped, then yes - that's a combined result of an old bad habit and a bit of disk space mismanagement of my part.
Atm, only glibc is build with debug symbols in /usr/lib/debug.

Technically, I think I could fit the whole system with splitdebug on the current partition, but that would be 2-3 days of rebuilding minimum (and it's pretty unlikely things like i.e. Qt 4.8 would play a role here).

Any ideas about the most likely culprit ? If it's just X stack (libX11, libxcb, etc.), that wouldn't take that long.
...though firefox itself is only as stripped as it was when I fetched it.

Anyway, I'm rebuilding most of X stack (around 39 various libs that I've noted in ldd output of (mostly) libxul) with splitdebug and '-g' (just splitdebug wasn't enough (in the hindsight, that was likely obvious - that added much more disk space use than I've expected).

For the time being, there's a bit more debug output from the rebuilt libs, but it would seem that most of the missing debug info is missing in firefox.
OK, I've rebuilt firefox 14.0.1 with splitdebug (but no debug strings), so there might be a better backtrace coming soon.

Now, on a semi-related note: some numbers (yes, I already admitted it's a bit of disk space mismanagement on my part)
on the build partition
1305MB - this much free space was left  when firefox finished building
499MB - this much space was left when when 'make install' (more or less) finished
411MB - this much space firefox uses after install

I'd say those numbers not quite add up, don't you say ?
Well, there's a bit more to see here, but much is still missing.

I wonder - glibc ?
One more 14.0.1 backtrace - either I didn't rebuilt enough or those symbols simply aren't there for the missing lines.
This time for something more vague, something I'm only aware of but while know it's reproducible, can't reproduce myself due to technicality.

http://poczta.onet.pl - after logging in, the page tends to crash almost immediately.

I don't have an account there, someone else does and it might be completely unrelated, but it started to crash at about the same time.
As I'm using FlashBlock, flash plugin shouldn't start upon loading the page, so if it's really related, Flash might just be coincidental here.

Perhaps helpful: /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Athlon(tm) XP 2500+
stepping        : 0
cpu MHz         : 1837.500
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up
bogomips        : 3675.00
clflush size    : 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts

On a not quite related note: Adobe is sure taking its time in regard of this set:
https://bugbase.adobe.com/index.cfm?event=bug&id=3155858
https://bugbase.adobe.com/index.cfm?event=bug&id=3154276
https://bugbase.adobe.com/index.cfm?event=bug&id=3158108
https://bugbase.adobe.com/index.cfm?event=bug&id=3161034
#13 topcrasher in 15 right now.  Adding wanted for STR.
Keywords: qawanted
This bug doesn't seem to be a regression in 15.0.
Version: Trunk → 14 Branch
Tried to reproduce this with Flash 11.2, Firefox 15.0b5, and Ubuntu 12.04 64-bit but was not able to. I used the URL in the original report and set up an account on http://poczta.onet.pl but neither crashed. Granted all of this was 64-bit. I'll have to set up a VM to see if I can reproduce this in a 32-bit environment. 

Since this will take some time, I'd appreciate it if anyone already in a 32-bit environment can report a reliable testcase to reproduce this crash.
I had an Ubuntu 11.10 32-bit VM lying around on a USB drive so I tried loading that up. Again, Flash 11.2 and Firefox 15.0b5, as in comment 51 this crash is not reproducible. Note that I can't seem to find any Flash content on http://poczta.onet.pl so if this is crashing reliably there for someone with this signature then it's probably not a Flash crash.

Can someone please provide me with further direction toward identifying a reproducible case?
Honestly, I really can't tell what makes the difference, but with http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-linux/1345153251/firefox-15.0.en-US.linux-i686.tar.bz2 the crash on AVON is still fully (and trivially) reproducible (that mail thing might have been just a coincidence).
Tried that build on Ubuntu 12.04 64-bit with Flash 11.2 32-bit and it did not crash. Does this only happen for you with an older version of Flash? If so, can you point me to somewhere I can download the exact version you are using? It also might be helpful to get the information from the Graphics section of your about:support page. It's possible this only reproduces on a specific set of hardware.
...what can I say, oops...

The problem was (most likely) a symbol clash.

I had libproxy.so.1 linked with libmozjs185.so.1.0.
After I rebuilt it so that it doesn't link with it, it seems I can no longer reproduce the crash, at least not as trivially.
Thanks Rafal, given that I'd like someone from Engineering to comment on the implications of comment 55. Does that give us a clue as to what might cause this crash? Is it a red herring? 

Given it's the #13 Fx15 topcrash I doubt it's caused simply by that symbol clash; it's not likely many betatesters have this configuration. I just don't know where to look for a reliable reproducible case at this point.
http://bit.ly/N5klRq
http://bit.ly/N5kvs1

If I'm looking correctly there are only 80 crashes for Linux with these signatures. The largest number is on Windows XP (3500). Given that, I think we should focus on Windows platforms.

Comments:
"This is a CONSTANT problem! When I am on eBay with more than one eBay window open, Firefox crashes over and over again. What is the conflict." 
"I clicked a button labelled "Exit Now" on a slideshow on password security on Ebay."

Though other comments simply mention "any page".
Will try on ebay with windows and linux, but it would be great if we had more information.
OS: Linux → All
I could not reproduce the crash on Windows XP - tried on the pages that were listed in the crash comments and in the comments of this bug:
http://facebook.com/
http://youtube.com/
http://ebay.com/
http://www.avonpolska.pl/ebrochure/ebrochure.html
Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0

No problems on Ubuntu 12.04 either with Flash 11.2 r202 and 15b5.

Add-on or hardware correlation would be great.
Most likely this an accidental match.
I've checked a few more sites that were crashing and they work correctly now.

Though in regard of spidermonkey: while libproxy/spidermonkey might be rare, i.e. gxine, polkitd and gjs have a hard dep on spidermonkey (though the first is quite old (*cough*abandoned*cough*), second and the other two, (third a hard dep of gnome-shell) would be hard to use in a way that would trigger the conflict with firefox).
Per comment 55, I close it as invalid.
Status: NEW → RESOLVED
Closed: 8 years ago7 years ago
Resolution: --- → INVALID
(In reply to Scoobidiver from comment #61)
> Per comment 55, I close it as invalid.

Agreed, removing qawanted as well. Thank you for your help with this issue Rafal.
Keywords: qawanted
Actually, thank you for your help.

If I didn't have this persistent pastebin (+ the reminders in form of coments from other people), it would take me much longer to recall certain old problem, that I didn't have and figure it out.
You need to log in before you can comment on or make changes to this bug.