crash in RtlpCallQueryRegistryRoutine | BaseThreadInitThunk with Flash in webapprt (caused by incorrect plugin-container launch)

VERIFIED FIXED in Firefox 16

Status

Firefox Graveyard
Webapp Runtime
P1
critical
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: eviljeff, Assigned: TimAbraldes)

Tracking

({crash, reproducible})

Trunk
Firefox 16
All
Windows 7
crash, reproducible
Bug Flags:
in-testsuite -

Details

(Whiteboard: [blocking-webrtdesktop1+], [appreview-blocker], [qa!], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Apps that use flash appear to be causing the runtime to crash after a few seconds (triggering the crash reporter).  I tried a few apps that worked and the common theme for ones that crash is flash.

To confirm my suspicion I hacked webapp.json to have about:addons as the origin and disabled the flash plugin, then reverted webapp.json.  The app no longer crashed.

Test case:
https://marketplace.mozilla.org/en-US/app/calcudoku
(the app has flash adverts)

I only noticed this in the 2012-07-04 Nightly.
Just got a crash as well with that app, but the crash report looks bizarre:

https://crash-stats.mozilla.com/report/index/bp-9b7d436c-7852-46e9-a539-afd902120705

Formal reports:

https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-07-05&signature=RtlQueryRegistryValues%20|%20BaseThreadInitThunk&version=WebappRuntime%3A16.0a1

Updated

5 years ago
Crash Signature: [@ RtlpCallQueryRegistryRoutine | BaseThreadInitThunk]

Updated

5 years ago
Summary: Flash usage causes crash after a few seconds → crash in RtlpCallQueryRegistryRoutine | BaseThreadInitThunk

Updated

5 years ago
Keywords: crash, reproducible

Updated

5 years ago
Whiteboard: [startupcrash]
Anthony or Ben - Something landed recently for flash signatures on nightly, right? Could these crashes be related to that? Any ideas on what this is?
Appears to happen on Firefox too:

https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=RtlQueryRegistryValues%20|%20BaseThreadInitThunk&reason_type=contains&date=07%2F05%2F2012%2015%3A48%3A08&range_value=1&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=RtlQueryRegistryValues%20|%20BaseThreadInitThunk

It's a windows-only crash.
Hardware: x86_64 → All
(Reporter)

Comment 4

5 years ago
When I tried in Nightly proper I didn't experience the crash.

Comment 5

5 years ago
The relevant possible bugs are:

* bug 769048 - Report on crashes from the Flash runtime
* bug 769721 - Force-enable OOPP for Flash users on Windows Vista+ 

Given the symptoms here, it seems very likely that bug 769721 is the cause of this behavior. I suspect that webapprt incorrectly was defaulting to run plugins in-process before (because the preferences are stored in firefox.js, not all.js). There may also be a bug with OOPP on Windows where we're looking in the wrong directory for plugin-container.exe or something like that.

This is probably due to incorrect code at http://hg.mozilla.org/mozilla-central/annotate/ee2c5f2928b6/ipc/glue/GeckoChildProcessHost.cpp#l108

The non-windows codepath uses NS_GRE_DIR correctly (probably because FF-on-XR on Linux forced somebody to fix this bug already!), but the windows codepath seems to assume that plugin-container will always be in the same directory as the launched executable, which is obviously incorrect for webapprt. So that's where this probably needs to be fixed.
Blocks: 769721

Comment 6

5 years ago
This blocks webapprt which is currently enabled for aurora(15), so we need to track this one way or another.
tracking-firefox15: --- → +
Summary: crash in RtlpCallQueryRegistryRoutine | BaseThreadInitThunk → crash in RtlpCallQueryRegistryRoutine | BaseThreadInitThunk with Flash in webapprt (caused by incorrect plugin-container launch)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> The non-windows codepath uses NS_GRE_DIR correctly (probably because
> FF-on-XR on Linux forced somebody to fix this bug already!)

Looks like it.
http://hg.mozilla.org/mozilla-central/rev/0b615190e79f
Assignee: nobody → tabraldes

Updated

5 years ago
tracking-firefox16: --- → ?

Updated

5 years ago
QA Contact: jsmith
Really easy ways to reproduce this bug:

1. Use the app Andy provided
2. Use the app here - http://pearce.org.nz/fullscreen/ and run the plugins
Whiteboard: [startupcrash]

Updated

5 years ago
Priority: -- → P1
Whiteboard: [blocking-webrtdesktop1+]
Target Milestone: --- → Firefox 16
Created attachment 639848 [details] [diff] [review]
Patch v1

The attached patch seems to do the right thing on Windows, and I *think* I've left the codepath for other OSes unmodified.  However, I don't have machines with other OSes on which I can build and run this patch.

This patch is running through tryserver:
  https://tbpl.mozilla.org/?tree=Try&rev=a018963ab58f
Attachment #639848 - Flags: review?(benjamin)
(In reply to Tim Abraldes from comment #9)
> Created attachment 639848 [details] [diff] [review]
> Patch v1
> 
> The attached patch seems to do the right thing on Windows, and I *think*
> I've left the codepath for other OSes unmodified.  However, I don't have
> machines with other OSes on which I can build and run this patch.
> 
> This patch is running through tryserver:
>   https://tbpl.mozilla.org/?tree=Try&rev=a018963ab58f

Tested this patch with the test cases in comment 8 and bundlr. No crashes detected. No obvious regressions either.

Updated

5 years ago
blocking-kilimanjaro: --- → ?

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+] → [blocking-webrtdesktop1+], [appreview-blocker]

Updated

5 years ago
Attachment #639848 - Flags: review?(benjamin) → review+

Comment 11

5 years ago
Also (perhaps in another bug) we should make webapprt use the same plugin prefs as Firefox:
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js?mark=898-911#898
(Reporter)

Comment 12

5 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> Also (perhaps in another bug) we should make webapprt use the same plugin
> prefs as Firefox:
> http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.
> js?mark=898-911#898

IMO, its not that straightforward.  e.g. Prefs are profile specific - which profile?  If the prefs are copied would changing the prefs in the profile after installing the app be reflected?  What happens if the Firefox profile used is deleted?

Comment 13

5 years ago
This is a default pref file, and is not related to a particular profile at all. I'm pretty sure that the equivalent webapprt file is http://mxr.mozilla.org/mozilla-central/source/webapprt/prefs.js
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> Also (perhaps in another bug) we should make webapprt use the same plugin
> prefs as Firefox:
> http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.
> js?mark=898-911#898

Agreed. I wonder if that might fix bug 749792 by caveat if we use those default prefs. Maybe add it to bug 749792?
(In reply to Jason Smith [:jsmith] from comment #14)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> > Also (perhaps in another bug) we should make webapprt use the same plugin
> > prefs as Firefox:
> > http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.
> > js?mark=898-911#898
> 
> Agreed. I wonder if that might fix bug 749792 by caveat if we use those
> default prefs. Maybe add it to bug 749792?

I've also filed bug 772447 (which might be a better place to put this) for reviewing the default prefs for desktop firefox and implementing ones that should be the web runtime, but are missing.
(Reporter)

Comment 16

5 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #13)
> This is a default pref file, and is not related to a particular profile at
> all. I'm pretty sure that the equivalent webapprt file is
> http://mxr.mozilla.org/mozilla-central/source/webapprt/prefs.js

Oh, okay.  I misunderstood.

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/3b579feaa4fc
Flags: in-testsuite-
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/3b579feaa4fc
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+], [appreview-blocker] → [blocking-webrtdesktop1+], [appreview-blocker], [qa+]
(Reporter)

Comment 19

5 years ago
Works for me in the latest Nightly, both for the app I originally mentioned (Calcudoku) and another app that was crashing (qb)
Status: RESOLVED → VERIFIED
Also tested on Mac to check to see if there were any regressions. No regressions detected.
Also tested on Win XP - no issues detected

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+], [appreview-blocker], [qa+] → [blocking-webrtdesktop1+], [appreview-blocker], [qa!]
tracking-firefox16: ? → ---
WebAppRT isn't shipping till FF16, and this is fixed there, so we're good to go here.
tracking-firefox15: + → -
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.