689818 - ABORT: wrong thread: 'PR_GetCurrentThread() == gSocketThread', file netwerk/protocol/http/nsHttpConnection.cpp, line 206

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Christian Holler (:decoder)]

Attachment: Crashing addon xpi, install in debug build to get the crash

We are currently working on a client/server model for fuzzing, which involves a jetpack addon in Firefox using a network connection to receive tests. While this works fine in optimized builds of Firefox, both nightly and aurora debug builds crash immediately after installation of the attached XPI with the mentioned assertion.

It would be very helpful to resolve this issue, as it blocks our testing on debug versions.

Comment 1

[Josh Matthews [:jdm]]

Attachment: Stack

gSocketThread != PR_GetCurrentThread. How peculiar.

Comment 2

[Josh Matthews [:jdm]]

The output shows we hit the "###!!! ASSERTION: must not instantiate twice: '!gSocketTransportService', file /Users/jdm/src/mozilla-central/netwerk/base/src/nsSocketTransportService2.cpp, line 103" assertion. The backtrace for that is terrifyingly long.

Comment 3

[Josh Matthews [:jdm]]

The problem here is that net.js in the addon is using Components.Constructor to instantiate the socket transport service. The Constructor call only ever calls CreateInstance, which unconditionally calls the factory method instead of returning the service object. There's debugging code that warns when this occurs, but only with certain #defines enabled. Overall, a poor experience, but I'm not certain if there's a way to improve the situation on the Gecko side without fixing bug 494946. This is definitely problematic JS code that needs fixing in the addon, however.

Comment 4

[Christian Holler (:decoder)]

Thanks Josh for your analysis, greatly appreciated.

This net.js file is part of the jetpack-io package which I'm not familiar with. Can we fix this in the jetpack-io JS code somehow?

Comment 5

[Benjamin Smedberg]

Mossop, assuming comment 4 is correct can you get somebody to fix the Jetpack SDK code?

Do we have any breakpad crash IDs? I'd like to see if this is a common issue in the field apart from this specific extension.

Comment 6

[Dave Townsend [:mossop]]

Looks like Irakli is on this already

Comment 7

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> Mossop, assuming comment 4 is correct can you get somebody to fix the
> Jetpack SDK code?
> 
> Do we have any breakpad crash IDs? I'd like to see if this is a common issue
> in the field apart from this specific extension.

If I understood :jdm correctly, problem is with my 'jetpack-io' library and not with with a jetpack code.

Comment 8

[Benjamin Smedberg]

Is the jetpack-io library not part of the SDK?

Comment 9

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

(In reply to Josh Matthews [:jdm] from comment #3)
> The problem here is that net.js in the addon is using Components.Constructor
> to instantiate the socket transport service. The Constructor call only ever
> calls CreateInstance, which unconditionally calls the factory method instead
> of returning the service object. There's debugging code that warns when this
> occurs, but only with certain #defines enabled. Overall, a poor experience,
> but I'm not certain if there's a way to improve the situation on the Gecko
> side without fixing bug 494946. This is definitely problematic JS code that
> needs fixing in the addon, however.

If I understand it correctly problem is with following lines right ?
https://github.com/Gozala/jetpack-io/blob/master/net.js#L16-17

Would this be a right fix here ?

const { createTransport } = CC['@mozilla.org/network/socket-transport-service;1').
                            getService(Ci.nsISocketTransportService)

Thanks!

Comment 10

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> Is the jetpack-io library not part of the SDK?

It's not, it's a third party library https://github.com/Gozala/jetpack-io

Comment 11

[Benjamin Smedberg]

Yes, I believe that .getService is the correct fix.

Comment 12

[Christian Holler (:decoder)]

Attachment: Patch to jetpack-io that fixes the problem

I patched the external jetpack-io package as advised (see patch from our internal repository) and I can confirm that this solves the assertion/crash problems.