Closed
Bug 669036
Opened 13 years ago
Closed 13 years ago
"ASSERTION: Getting architecture of plugin container failed!"
Categories
(Core :: IPC, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
firefox9 | --- | fixed |
People
(Reporter: jruderman, Assigned: jaas)
Details
(4 keywords, Whiteboard: [qa!])
Attachments
(4 files)
###!!! ASSERTION: Getting architecture of plugin container failed!: 'NS_SUCCEEDED(rv) && pluginContainerArchs != 0', file /Users/jruderman/trees/mozilla-central/ipc/glue/GeckoChildProcessHost.cpp, line 250
Reporter | ||
Comment 1•13 years ago
|
||
Reporter | ||
Comment 2•13 years ago
|
||
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.
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.
Attachment #557055 -
Flags: review?(benjamin)
Updated•13 years ago
|
Attachment #557055 -
Flags: review?(benjamin) → review+
pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/13b9a3f0eb42
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.
Considering comment6, setting resolution to Verified Fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•