731881 - ~nsHttpChannel calls nsXPConnect::GetXPConnect off the main thread via ~XPCTraceableVariant?

Status: RESOLVED INCOMPLETE

(Core :: Networking: HTTP, defect)

Description

[Andrew McCreight [:mccr8]]

I noticed this crash stack, which is hitting a release assertion that checks that GetXPConnect() isn't called off the main thread.  It looks like nsHttpChannel has some kind of hash table of nsIVariants, and the destructor for an XPCTraceableVariant is trying to grab a lock from XPConnect.

https://crash-stats.mozilla.com/report/index/96622599-ebc5-40bc-b0ae-5daaa2120226

It could be an addon or just the code itself, I don't know.

Comment 1

[Andrew McCreight [:mccr8]]

I only see a single instance of this on 13, and no MOZ_Assert at all in 12, so maybe it is just something weird...

Comment 2

[Andrew McCreight [:mccr8]]

Another one:

https://crash-stats.mozilla.com/report/index/bb63ad3f-0e04-47be-997e-352b02120229

Comment 3

[Andrew McCreight [:mccr8]]

I don't see GetXPConnect() in crash stats any more.

Comment 4

[Scoobidiver (away)]

I see a few crashes: https://crash-stats.mozilla.com/report/list?signature=nsXPConnect%3A%3AGetXPConnect%28%29

Comment 5

[Ahmad Saleem]

Got crash just now: https://crash-stats.mozilla.com/report/index/bp-9264aa21-ebfa-416e-ae26-21eab2121207

Seeing graph of it shows it somehow in high numbers in December 6 build of Nightly.
Sorry for bumping this...

Comment 6

[Scoobidiver (away)]

(In reply to Zlip792 from comment #5)
> Got crash just now:
> https://crash-stats.mozilla.com/report/index/bp-9264aa21-ebfa-416e-ae26-
> 21eab2121207
The stack trace is different. It's another issue.

Comment 7

[Andrew McCreight [:mccr8]]

I don't see any crashes like this in the top lists any more.