Last Comment Bug 669036 - "ASSERTION: Getting architecture of plugin container failed!"
: "ASSERTION: Getting architecture of plugin container failed!"
Status: VERIFIED FIXED
[qa!]
: assertion, testcase, verified-aurora, verified-beta
Product: Core
Classification: Components
Component: IPC (show other bugs)
: Trunk
: x86_64 Mac OS X
: -- normal (vote)
: ---
Assigned To: Josh Aas
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-02 21:05 PDT by Jesse Ruderman
Modified: 2011-12-09 01:16 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
testcase (48 bytes, text/html)
2011-07-02 21:05 PDT, Jesse Ruderman
no flags Details
stack trace (1.35 KB, text/plain)
2011-07-02 21:06 PDT, Jesse Ruderman
no flags Details
my mozconfig (476 bytes, text/plain)
2011-07-02 21:06 PDT, Jesse Ruderman
no flags Details
fix v1.0 (1.28 KB, patch)
2011-08-30 18:12 PDT, Josh Aas
benjamin: review+
Details | Diff | Splinter Review

Description Jesse Ruderman 2011-07-02 21:05:41 PDT
Created attachment 543646 [details]
testcase

###!!! ASSERTION: Getting architecture of plugin container failed!: 'NS_SUCCEEDED(rv) && pluginContainerArchs != 0', file /Users/jruderman/trees/mozilla-central/ipc/glue/GeckoChildProcessHost.cpp, line 250
Comment 1 Jesse Ruderman 2011-07-02 21:06:01 PDT
Created attachment 543647 [details]
stack trace
Comment 2 Jesse Ruderman 2011-07-02 21:06:44 PDT
Created attachment 543648 [details]
my mozconfig
Comment 3 Josh Aas 2011-08-30 15:18:57 PDT
The problem is that we attempt to look up the architecture on the plugin binary with a bad path:

.../NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container

Note that "/Contents/MacOS/plugin-container.app" has been appended twice.
Comment 4 Josh Aas 2011-08-30 18:12:54 PDT
Created attachment 557055 [details] [diff] [review]
fix v1.0

The assertion is coming from the child process. The problem is that we append the path to the child process bundle even if we started with the child process binary location.
Comment 5 Josh Aas 2011-09-06 21:58:55 PDT
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/13b9a3f0eb42
Comment 6 Vlad [QA] 2011-12-05 05:40:20 PST
I have verified this using the test case from the attachment on:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0 beta 4
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111127 Firefox/10.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111204 Firefox/11.0a1

The process of getting the add-on worked as expected (no add-ons were found).
This is the right functionality or I have to consider other aspects?
Can I change the status of this bug tu Verified?

Thanks.
Comment 7 Vlad [QA] 2011-12-09 01:16:43 PST
Considering comment6, setting resolution to Verified Fixed

Note You need to log in before you can comment on or make changes to this bug.