775095 - Hovering over Flash content crashes whole browser

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Rafał Mużyło]

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.

Comment 1

[Loic]

Could post some crash reports links, please? (type about:crashes)

Comment 2

[Rafał Mużyło]

(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.

Comment 3

[Scoobidiver (away)]

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)?

Comment 4

[Rafał Mużyło]

Attachment: 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).

Comment 5

[Scoobidiver (away)]

It's odd that Firefox crashes if OOPP is enabled. Please try the new profile.

Comment 6

[Rafał Mużyło]

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...?

Comment 7

[Rafał Mużyło]

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.

Comment 8

[Rafał Mużyło]

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...?).

Comment 9

[Scoobidiver (away)]

Unfortunately, without a stack trace, nothing can be done. Try to install Nightly to get one: http://nightly.mozilla.org/.

Comment 10

[Rafał Mużyło]

(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)

Comment 11

[Rafał Mużyło]

OK, I found http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-release-linux-debug/1342218862/firefox-14.0.1.en-US.linux-i686.tar.bz2.

Now, the other part...?

Comment 12

[Scoobidiver (away)]

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

Comment 13

[Rafał Mużyło]

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.

Comment 14

[Scoobidiver (away)]

(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.

Comment 15

[Rafał Mużyło]

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 ?

Comment 16

[Rafał Mużyło]

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 ?

Comment 17

[Rafał Mużyło]

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 ?".

Comment 18

[Benjamin Smedberg]

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.

Comment 19

[Rafał Mużyło]

(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 ?

Comment 20

[Rafał Mużyło]

Every single -debug from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ that I've tried was the same - stripped.

Comment 21

[Rafał Mużyło]

OK, that funny *cough*ridd..*cough*.
Both http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/ and http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ don't have debug spew but aren't stripped.

http://crash-stats.mozilla.com/report/index/bp-b8c0921e-9a3f-4e80-a332-855c32120719
http://crash-stats.mozilla.com/report/index/bp-b1a7f80c-b0b9-4d5a-90d8-f956d2120719

Both crash the same.

Comment 22

[Rafał Mużyło]

Attachment: thread apply all bt full from 17.0a1

In case those error reports don't include anything again, 'thread apply all bt full' for 17.0a1.

Comment 23

[Rafał Mużyło]

"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 ?).

Comment 24

[Rafał Mużyło]

Sorry, browser didn't refresh all the fields (again).

Comment 25

[Rafał Mużyło]

On a semi-related note: perhaps it would be a good idea if those -debug builds were *not* stripped.

Comment 26

[Rafał Mużyło]

Any info I could try to provide or is it simply waiting for someone on javascript team to find time to look at ?

Comment 27

[Rafał Mużyło]

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).

Comment 28

[Rafał Mużyło]

It seems to be fixed in aurora on the same date - still no closer to the particular commit.

Comment 29

[Rafał Mużyło]

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.

Comment 30

[Rafał Mużyło]

...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.

Comment 31

[Rafał Mużyło]

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.

Comment 32

[Rafał Mużyło]

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.

Comment 33

[Rafał Mużyło]

...correction of comment 31: ...more crash testing with today's nightly debug *beta*...

Comment 34

[Rafał Mużyło]

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.

Comment 35

[David Mandelin [:dmandelin]]

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.

Comment 36

[Rafał Mużyło]

(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.

Comment 37

[David Mandelin [:dmandelin]]

(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.

Comment 38

[Rafał Mużyło]

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.

Comment 39

[Rafał Mużyło]

Attachment: backtrace of the crash

Just rechecked with http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-linux/1343757457/firefox-15.0.en-US.linux-i686.tar.bz2 - no change.
Sent a few crash reports in the process, i.e.:
http://crash-stats.mozilla.com/report/index/bp-fac31f0d-eed4-4d54-bdd8-1ab622120731
http://crash-stats.mozilla.com/report/index/bp-81ad0287-c6f1-414f-a990-ad91f2120731
http://crash-stats.mozilla.com/report/index/bp-8a699255-5268-44fd-b824-501012120731

Attaching 3 'thread apply all bt full' from a few of other crashes from this set.

Comment 40

[Rafał Mużyło]

Attachment: backtrace of the crash, take 2

Comment 41

[Rafał Mużyło]

Attachment: backtrace of the crash take 3

Comment 42

[David Mandelin [:dmandelin]]

(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?

Comment 43

[Rafał Mużyło]

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.

Comment 44

[Rafał Mużyło]

...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.

Comment 45

[Rafał Mużyło]

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 ?

Comment 46

[Rafał Mużyło]

Attachment: current backtrace from ff 14.0.1

Well, there's a bit more to see here, but much is still missing.

I wonder - glibc ?

Comment 47

[Rafał Mużyło]

Attachment: another backtrace from 14.0.1

One more 14.0.1 backtrace - either I didn't rebuilt enough or those symbols simply aren't there for the missing lines.

Comment 48

[Rafał Mużyło]

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

Comment 49

[Lukas Blakk [:lsblakk] use ?needinfo]

#13 topcrasher in 15 right now.  Adding wanted for STR.

Comment 50

[Scoobidiver (away)]

This bug doesn't seem to be a regression in 15.0.

Comment 51

[u279076]

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.

Comment 52

[u279076]

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?

Comment 53

[Rafał Mużyło]

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).

Comment 54

[u279076]

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.

Comment 55

[Rafał Mużyło]

...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.

Comment 56

[u279076]

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.

Comment 57

[Virgil Dicu [:virgil] [QA]]

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.

Comment 58

[Simona Badau, Desktop Test Engineering]

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

Comment 59

[Virgil Dicu [:virgil] [QA]]

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.

Comment 60

[Rafał Mużyło]

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).

Comment 61

[Scoobidiver (away)]

Per comment 55, I close it as invalid.

Comment 62

[u279076]

(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.

Comment 63

[Rafał Mużyło]

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.