669036 - "ASSERTION: Getting architecture of plugin container failed!"

Status: VERIFIED FIXED

(Core :: IPC, defect)

Description

[Jesse Ruderman]

Attachment: 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]

Attachment: stack trace

Comment 2

[Jesse Ruderman]

Attachment: my mozconfig

Comment 3

[Josh Aas]

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]

Attachment: 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]

pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/13b9a3f0eb42

Comment 6

[Vlad [QA]]

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

Considering comment6, setting resolution to Verified Fixed