Binary XPCOM components registration or handling procedure bug crashes Firefox 3.6.4 (no problem with 3.6.3 and earlier)

RESOLVED INCOMPLETE
(NeedInfo from)

Status

()

defect
--
critical
RESOLVED INCOMPLETE
9 years ago
3 years ago

People

(Reporter: mr, Unassigned, NeedInfo)

Tracking

({regression})

3.6 Branch
x86
All
Points:
---

Firefox Tracking Flags

(blocking1.9.2 -, status1.9.2 wanted)

Details

(Whiteboard: [oopp-watchlist])

Attachments

(1 attachment)

Reporter

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4

We found an issue in 3.6.4 that is related to the to the binary XPCOM components registration or handling procedure. Our iMacros extension from contains a file called XpcomOpusConnector.dll - normally the file just sits in this directory and does nothing (unless iMacros for Firefox is started/used with our so called Scripting Interface).

But since 3.6.4 the pure presence of this file stops Firefox from loading! Even on Linux, although XpcomOpusConnector.dll is a Windows binary.

I will now upload a new version of iMacros to AMO without that file, but please investigate and fix this issue soon. It breaks a core function of our extension. If there is anything that we can do from our site, please let me know.

Reproducible: Always

Steps to Reproduce:
Install iMacros for Firefox V6.6.5, https://addons.mozilla.org/en-US/firefox/addon/3863/versions/?page=1#version-6.6.5.0


Actual Results:  
Firefox will no longer start after reboot, see also the user reports at http://forum.iopus.com/viewtopic.php?f=11&t=10454

Expected Results:  
Firefox starts!
Reporter

Updated

9 years ago
Summary: Binary XPCOM components registration or handling procedure bug crashes Firefox → Binary XPCOM components registration or handling procedure bug crashes Firefox 3.6.4 (no problem with 3.6.3 and earlier)
Reporter

Updated

9 years ago
Version: unspecified → 3.6 Branch

Updated

9 years ago
Keywords: regression

Updated

9 years ago
blocking1.9.2: --- → ?

Comment 1

9 years ago
Just having the Firefox extension is not enough to cause the issue. I had to install the free trial of iMacros http://iopus.com/download/

Comment 2

9 years ago
The windows crash handler produced the following set of files. http://dl.dropbox.com/u/686313/Windows%20Firefox%20dump.zip

Updated

9 years ago
Attachment #453793 - Attachment mime type: application/octet-stream → text/plain
Reporter

Comment 4

9 years ago
>I had to install the free trial of iMacros http://iopus.com/download/

Strange. We also saw the issue on Linux, and for Linux only the iMacros Firefox addon is available.

Comment 5

9 years ago
I think we may be seeing a similar behaviour with the "MR Tech toolkit" extension https://addons.mozilla.org/en-US/firefox/addon/421/ (currently release 6.0.4).

One of our users reported problems after we updated to Firefox 3.6.4 (BTW this is the SL5/RHEL5 Linux package), testing it myself I find that after adding the extension it restarts firefox and seems ok, but after quitting any later attempt to start it results in a segv.

Going into the extensions/{9669CC8F-B388-42FE-86F4-CB5E7F5A8BDC}/ and taking a look about I find that if I manually rename components/nightly.xpt to (say) components/nightly.xpt.OFF then firefox no longer crashes and the extension appears to work ok.

Another hack is to remove the extensions.ini which lets firefox work *just* for the next time it is started (and then it gets recreated with the same contents) so it seems to be related to whatever processing is done there.

I'm tempted to tweak our firefox wrapper we have to always delete all the extensions.ini files but that does seem rather evil...

 -- Jon

Comment 6

9 years ago
you register two category entries:
       content-policy,@iopus.com/requestwatcher;1,@iopus.com/requestwatcher;1
       net-channel-event-sinks,@iopus.com/requestwatcher;1,@iopus.com/requestwatcher;1

the latter is triggered by nsIOService::OnChannelRedirect,
and the former is triggered by content policies, the also will definitely trigger.

If you don't want it to do anything, you need to dynamically register them (for the process) based on some condition

As for why it's getting stuck, that's because of how you're using COM

it isn't our problem :/

Comment 7

9 years ago
(In reply to comment #5)
You should file a separate bug.

Updated

9 years ago
Whiteboard: [oopp-watchlist]

Comment 8

9 years ago
(In reply to comment #7)
> (In reply to comment #5)
> You should file a separate bug.

Sorry I thought it might be the same issue.  New bug filed (https://bugzilla.mozilla.org/show_bug.cgi?id=574458)
Reporter

Comment 9

9 years ago
Hi timeless (In reply to comment #6)

I am not sure what you mean with your comments.

The DLL has been there and unchanged for years. What change in 3.6.4 would trigger this crash? And on Linux, this DLL has no function whatsoever and Firefox still crashes (= does not start). Is there anything we should do in  another way now??

"As for why it's getting stuck, that's because of how you're using COM "
It is not clear to us what you mean. Is it related to dll XPCOM or Javascript XPCOM?

Comment 10

9 years ago
the dll calls MSCOM...

as for the linux side, someone would have to trace it to something happening, kbrosnan provided a stack trace for the windows side, but i don't have one to look at for the linux side.
(In reply to comment #9)
> The DLL has been there and unchanged for years. What change in 3.6.4 would
> trigger this crash? And on Linux, this DLL has no function whatsoever and
> Firefox still crashes (= does not start). Is there anything we should do in 
> another way now??

Without knowing what your DLL does there's no way for us to know. We changed a lot (234 bugs) and only you know what interfaces/services you were using.

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.2%3A.4-fixed

Anything in there look relevant to what you're doing? Maybe an hg diff of 3.6.3 vs 3.6.4 and focus on changes in .idl files?
blocking1.9.2: ? → needed
Reporter

Comment 12

9 years ago
Would the xpt DLL source code help you? It is actually a pretty small project and I can provide it.

But since the issue also happens on Linux (where the dll does not work), I assume it is not related to a function of the DLL anyway. Does Firefox parse xpt files at startup?

We found that renaming IOpusConnector.xpt to IOpusConnectorYYYY.xpt avoid the startup crash (of course, then the extension features that require the xpt no longer work, too)

Comment 13

9 years ago
as long as the license isn't poisonous, it couldn't hurt. i can't make any guarantees.
Reporter

Comment 14

9 years ago
I am not sure what you mean with "poisonous" in this context. iMacros for Firefox is under a proprietary license but open source. So this does not prevent you (or anybody else interested in it) to have a look at the source code.

But on the other hand, we are pretty sure that "our" bug is the same as

https://bugzilla.mozilla.org/show_bug.cgi?id=574458

So probably it makes sense to wait until 574458 is fixed before continue to work on this one.

Updated

9 years ago
Duplicate of this bug: 577093
blocking1.9.2: needed → -
Need to determine if this bug can be closed. Related items have been fixed. iMacros for Firefox 8.9.6 WFM
Version 6.5.0.0 cannot be installed on 
Version 	45.0
Build ID 	20160303134406
Flags: needinfo?(mr)
Closing this as incomplete due to inactivity and lack of response. 
Feel free to reopen the bug and provide a test case with updated info, if the issue still reproduces on a current build.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.