Crash in mozilla::net::nsHttpTransaction::Close

RESOLVED WONTFIX

Status

()

--
critical
RESOLVED WONTFIX
a year ago
a year ago

People

(Reporter: jmaline, Unassigned)

Tracking

(Blocks: 1 bug, {crash})

52 Branch
x86
Windows 7
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

a year ago
This bug was filed from the Socorro interface and is 
report bp-12e1346a-7305-4bac-b450-2fb3b0170726.
=============================================================
Getting repeatable crashes from FF ESR 52.2. Seems to be loading a company intranet site (various implementation technologies) but all seem to be using NTLM authentication.

Updated

a year ago
Component: General → Networking: HTTP
Keywords: crash
Product: Firefox → Core
(In reply to John Maline from comment #0)
> This bug was filed from the Socorro interface and is 
> report bp-12e1346a-7305-4bac-b450-2fb3b0170726.
> =============================================================
> Getting repeatable crashes from FF ESR 52.2. Seems to be loading a company
> intranet site (various implementation technologies) but all seem to be using
> NTLM authentication.

Honza, could you take a look at this bug? No idea if this has something to do with NTLM.
Flags: needinfo?(honzab.moz)
According the dump: this->mPipeOut.mRawPtr was nullptr.  We've had some issues around this member in the past in bug 1153929.

Valentin, do you think this one could be another instance of the same problem?
Flags: needinfo?(honzab.moz) → needinfo?(valentin.gosu)
(In reply to Honza Bambas (:mayhemer) from comment #2)
> According the dump: this->mPipeOut.mRawPtr was nullptr.  We've had some
> issues around this member in the past in bug 1153929.
> 
> Valentin, do you think this one could be another instance of the same
> problem?

It does seem related, but it's not exactly the same problem.
In my example, mRawPtr was not null, but the vtable of the underlying object was:
http://searchfox.org/mozilla-central/rev/09c065976fd4f18d4ad764d7cb4bbc684bf56714/netwerk/protocol/http/nsHttpTransaction.cpp#418

I think there is definitely a problem with the pipes code, or how we use pipes, but I haven't been able to figure it out.
Flags: needinfo?(valentin.gosu)
(Reporter)

Comment 4

a year ago
Turned off network.http.pipelining and network.http.proxy.pipelining. Now both in default false state.

A quick smoke test of sites that used to crash show no crash after the change.

Updated

a year ago
Blocks: 1196787
Pipelining is removed on release 54 already (bug 1340655) and this crash is reported on ESR 52. Are we going to disable it on ESR 52 as well in order to solve this issue?
Flags: needinfo?(mcmanus)
(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #5)
> Pipelining is removed on release 54 already (bug 1340655) and this crash is
> reported on ESR 52. Are we going to disable it on ESR 52 as well in order to
> solve this issue?

Pipeline was turned off on desktop for years, actually I do not think it was ever on. It was on on android only until 55. I have disable it on android in bug 1348675. I think we cannot do much for 52 esr since this are users setting, maybe we can overwrite them...
its disabled on 52..
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(mcmanus)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.