Firefox 54 on Linux - new Flash Player crash

UNCONFIRMED
Unassigned

Status

()

defect
P5
critical
UNCONFIRMED
2 years ago
2 years ago

People

(Reporter: richard, Unassigned)

Tracking

({crash, regressionwindow-wanted, stackwanted})

54 Branch
Unspecified
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/602.3.12 (KHTML, like Gecko) Version/10.0.2 Safari/602.3.12

Steps to reproduce:

Using Firefox 54 on Ubuntu, latest Flash Player (26.0.0.131):

* log in to www.openstreetmap.org, zoom into an area, and from the edit menu select 'Edit with Potlatch 2'
* when editor has loaded, click anywhere in the map area that is not an object


Actual results:

Firefox crashes.


Expected results:

...Firefox should probably not crash.

No problem with previous versions of Firefox, in Firefox 54 for OS X, or in Chromium for either OS X or Ubuntu. This appears to be a regression introduced with Firefox 54 for Ubuntu.

Original OpenStreetMap ticket: https://trac.openstreetmap.org/ticket/5457

Let me know if you need me to set up an instance without a login barrier.

Comment 1

2 years ago
If it's a regression, could you use the tool mozregression to narrow down a regression range.
See http://mozilla.github.io/mozregression/ for details.
Run the command "mozregression --good=53" (or 52) then for each nightly build launched, make the test and enter if it's good or bad. After the run, paste here the final pushlog.
Flags: needinfo?(richard)

Comment 2

2 years ago
Also and perhaps more importantly, is there a crash report ID (from about:crashes) for the crash? That will probably only work/produce useful data on mozilla.org builds, not ubuntu-provided builds of Firefox.

I tried your steps to reproduce on Firefox nightly 64 (mozilla.org build) with Flash 25.0.0.171 and couldn't reproduce. I'll try a Flash upgrade momentarily.

Comment 3

2 years ago
Couldn't reproduce on nightly with Flash 26.0.0.131 either.

Comment 4

2 years ago
Ran mozregression on the nightly builds, can confirm 2017-02-15 is good, 2017-02-16 is bad (no mousewheel zoom and easy to crash Flash just by clicking not on any object).  Re-ran each singly to check and it's repeatable.
Push log url is given as: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0a7831d838f793a263456df62f95a615472a7f95&tochange=6cefe01ca7744d6ac3960c69eac833e2e65f7f8f

A crash report (from released 54.0 (64bit)) is: bp-8d486210-21ba-4c26-89b8-bef961170620

I'm running on 64 bit Mint 17.3 (ie Ubuntu 14.x derived).  From other reports it does seem Linux-specific?

I had tried reinstalling older Flash 25.0, that (apart from having to confirm to run an old version) makes no difference, ie. 54.0 still has the problem.

hope this helps,
'Cebderby' on OpenStreetMap

Comment 5

2 years ago
Regression would be from forcing all Flash to be windowless mode, bug 1337781. I suspect that if this Flash element were marked as wmode="opaque" this issue would be reproducible before FF54/15-Feb nightly.

We're not going to go back on that, so we need to figure out what the crash is. Unfortunately the stack of that crash report is gibberish.

Ted, remind me if/how I or somebody could debug a nightly or release build with separate symbol download?

cebutler would you be able/willing to do a Firefox build locally (with symbols) and attach a debugger to get a better stack?
Flags: needinfo?(ted)
Flags: needinfo?(cebutler.derby.uk)

Comment 6

2 years ago
Was trying to see if I could build Firefox but the python script suddenly wanted to install and uninstall a huge bunch of packages and left my system in a bad state.  So you are on your own for now, while I try and sort this mess out.
Flags: needinfo?(cebutler.derby.uk)

Comment 7

2 years ago
Ok, operating system is back in one piece again (no idea what bootstrap.py was thinking in removing my xorg, xserver-xorg and a bunch of other packages...  but seem to be ok again now.  Got the current mozilla-central nightly using Mercurial and built it ok (no changes to any settings at present).  Can reproduce the problems, but the Flash crash reporting is disabled and will need some specific instructions on any debugger use (have gdb installed and can attach to main process but not seeing anything useful).  Will the nightly be set to have the required symbols or do I need to find the place to set MOZ_DEBUG_SYMBOLS=1 and possibly ac_add_options --enable-debug-symbols="-gdwarf-2" as well, and recompile?

Comment 8

2 years ago
hi, i am now on ff nightly with ubuntu 16.04 GNOME(before this, i had ubuntu 16.04 UNITY -> same problems), and i try to zoom in on this official government site . I have latest flash from this site -> http://www.duinsoft.nl/packages.php?t=en

I am 'third' user from this topic -> https://trac.openstreetmap.org/ticket/5457

and i am topis starter here -> http://forums.mozillazine.org/viewtopic.php?f=9&t=3031146

ff nightly, and ff 54(stable)hangs and my middle mouse wheel for zooming-in/out does not work.

with ff(52) ESR , it works ...

try it yourself ... -> https://ccff02.minfin.fgov.be/cadgisweb/?local=nl_BE

Updated

2 years ago
Severity: normal → critical
Keywords: crash, stackwanted
OS: Unspecified → Linux
(In reply to Benjamin Smedberg [:bsmedberg] from comment #5)
> Ted, remind me if/how I or somebody could debug a nightly or release build
> with separate symbol download?

If you've got GDB 7.9 or newer, you can just load this script:
https://gist.github.com/luser/193572147c401c8a965c

You'll need to provide a matching source checkout and use `set substitute-path` if you want source-level debugging to work.
Flags: needinfo?(ted)
It is an unfortunate fact of life that the core plugin engineering team won't be able to spend any time on this bug. I will happily help with mentoring and advice to the point where we have a stack and can figure out whether this is an Adobe or Mozilla problem.
Priority: -- → P3

Updated

2 years ago
Priority: P3 → P5
(Reporter)

Comment 11

2 years ago
Assuming that not all Flash apps crash with Firefox, can you offer any suggestions on how to workaround this bug from the Flash/ActionScript side of things?

(I don't have a Linux machine to test on so would be doing this "blind".)
I don't know. It might be interesting to debug-printf the actions that the SWF file takes for the click in question and try removing calls until it doesn't crash. Or use a Linux VM for debugging... or, since Flash is on its last legs, what would it take to stop using Flash at all?
(Reporter)

Comment 13

2 years ago
Potlatch 2 isn't currently the default OSM editor - that's in Javascript. It's the previous default, still available as an option, which we keep around because it does some things better and some people find it more comfortable. In due course I'll package it up as an AIR app anyway to remove the browser dependency.
Flags: needinfo?(richard)
(In reply to cebutler.derby.uk from comment #4)
> A crash report (from released 54.0 (64bit)) is:
> bp-8d486210-21ba-4c26-89b8-bef961170620

This crash report smells like it's from a distro build that has no symbols on Mozilla end. Can you try to get a crash report from, say, a nightly build?
(In reply to Mike Hommey [:glandium] from comment #14)
> ... Can you try to get a crash report from, say, a nightly build?

Not getting one from nightly builds (launching via mozregression_gui, using default 64bit, opt choices).  The browser catches the crash, presents the 'plugin has crashed' screen with the report submission button, but consistently get 'submission failed', with no new entries on about:crashes and no backlogged reports.

Also compiled from source to try to get full symbols, but that build does not show the 'submit report' button at all on the plugin crash screen.  (And as the browser session stays up, as it is the plugin that dies, gdb shows nothing attached to the main process).

Any ideas how to enable crash reporting/transmission in nightly or self-compiled?  And/or is it possible to attach gdb to the plugin subprocess?  Another issue with gdb was that the symbols.py linked to (comment 9) works with gdb (but the 64bit process won't attach) but does not seem to work with gdb64?

To reproduce the crash, I guess you would need to create an account at openstreetmap.org.  You don't actually need to alter the map at all, just log in, zoom in fairly close somewhere in the normal view, select edit with Potlatch, click anywhere away from an object.

There's also the mystery of the non-working mousewheel zoom, which may not have got a mention in this thread as it's not a crash, but it happens in released 54 and nightlies from mid Feb the same as the crash.
You need to log in before you can comment on or make changes to this bug.