Closed Bug 594487 Opened 14 years ago Closed 14 years ago

[SeaMonkey] leak test: "Exception / NS_ERROR_XPC_GS_RETURNED_FAILURE / nsIJSCID.getService / messageWakeupService.js :: anonymous :: line 56"

Categories

(Core :: IPC, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla2.0b7

People

(Reporter: sgautherie, Assigned: azakai)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

{
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80570016
(NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult:
"0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame ::
file:///builds/slave/comm-central-trunk-macosx-debug/build/objdir/mozilla/dist/SeaMonkeyDebug.app/Contents/MacOS/components/messageWakeupService.js
:: anonymous :: line 56"  data: no]
}

Fwiw, KaiRo seemed to wonder whether this should be active at all in current SeaMonkey setup...
Code is
{
53   get messageManager() {
54     if (!this._messageManager)
55       this._messageManager = Cc["@mozilla.org/parentprocessmessagemanager;1"].
56                              getService(Ci.nsIFrameMessageManager);
57     return this._messageManager;
58   },
}
Blocks: 594430
No longer blocks: 563643
I'm not familiar with how SeaMonkey differs from stock Firefox, but must be some difference that is the issue. Is MOZ_IPC enabled there? Is the messagemanager stuff usable? And the parentprocessmessagemanager in particular?
http://mxr.mozilla.org/comm-central/search?string=MOZ_IPC&case=1&find=%2Fsuite%2F
MOZ_IPC is disabled.

I don't know how to check/answer your two other questions.
(In reply to comment #3)
> MOZ_IPC is disabled.

That must be the problem then.

I guess the solution is to disable the wakeup service if MOZ_IPC is disabled, something like in this (untested) patch? Or is there a better way?
I have no idea why Serge filed another bug for this, when bug 594430 will fix this by just packaging the message wakeup service so that it's available.

What I wondered about was why we even try to access it in non-IPC builds. Given that we want to enable OOPP ASAP (i.e. as soon as we can build with some kind of libxul), we should package it anyhow, though.
Forget the part of my comment that talks about fixing, as the failure happens in builds that don't run from packages but from dist/bin.

The problem is really that we shouldn't include IPC-only code in non-IPC builds and Alon's patch is probably correct.
Comment on attachment 473190 [details] [diff] [review]
Patch?
[Checked in: Comment 12]

I can't test due to bug 562820, but that's exactly what I was thinking about.
Attachment #473190 - Flags: review?(mark.finkle)
Comment on attachment 473190 [details] [diff] [review]
Patch?
[Checked in: Comment 12]

looks OK to me
Attachment #473190 - Flags: review?(mark.finkle) → review+
Comment on attachment 473190 [details] [diff] [review]
Patch?
[Checked in: Comment 12]

"approval2.0=?":
Trivial build fix for non-MOZ_IPC builds, like SeaMonkey ones.
Attachment #473190 - Flags: approval2.0?
Assignee: nobody → azakai
Ping for approval2.0.
Comment on attachment 473190 [details] [diff] [review]
Patch?
[Checked in: Comment 12]

a=NPOTB ... I'll push in a few minutes.
Attachment #473190 - Flags: approval2.0?
http://hg.mozilla.org/mozilla-central/rev/1d2729c14e46
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
V.Fixed, per
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1284865960.1284868738.29807.gz&fulltext=1
Linux comm-central-trunk leak test build on 2010/09/18 20:12:40
Status: RESOLVED → VERIFIED
Flags: in-testsuite-
Hardware: x86 → All
Attachment #473190 - Attachment description: Patch? → Patch? [Checked in: Comment 12]
Fwiw, should nsIMessageWakeupService.idl be somehow "ifdef'ed" too?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: