Closed
Bug 1090238
Opened 10 years ago
Closed 10 years ago
SPDY crashes on Facebook
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
Tracking | Status | |
---|---|---|
firefox35 | --- | unaffected |
firefox36 | --- | fixed |
firefox-esr31 | --- | unaffected |
People
(Reporter: khuey, Assigned: mcmanus)
References
Details
(Keywords: csectype-uaf, sec-critical, Whiteboard: [dupe 1089749?])
This happens constantly while accessing Facebook. We're accessing deleted memory (0x5a5a5a5a).
xul.dll!nsTHashtable<nsBaseHashtableET<nsCStringHashKey,nsAutoPtr<nsXBLPrototypeBinding> > >::RemoveEntry(const nsACString_internal & aKey) Line 175 C++
> xul.dll!mozilla::net::SpdySession31::CleanupStream(mozilla::net::SpdyStream31 * aStream, tag_nsresult aResult, mozilla::net::SpdySession31::rstReason aResetCode) Line 908 C++
xul.dll!mozilla::net::SpdySession31::CloseTransaction(mozilla::net::nsAHttpTransaction * aTransaction, tag_nsresult aResult) Line 2424 C++
xul.dll!mozilla::net::nsHttpConnectionMgr::OnMsgCancelTransaction(int reason, void * param) Line 2424 C++
xul.dll!mozilla::net::nsHttpConnectionMgr::nsConnEvent::Run() Line 626 C++
xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 830 C++
xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 265 C++
xul.dll!nsSocketTransportService::Run() Line 742 C++
xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 830 C++
xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 265 C++
xul.dll!mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate * aDelegate) Line 368 C++
xul.dll!MessageLoop::RunHandler() Line 227 C++
xul.dll!MessageLoop::Run() Line 201 C++
xul.dll!nsThread::ThreadFunc(void * aArg) Line 359 C++
Assignee | ||
Comment 1•10 years ago
|
||
kyle I expect this is a dup of 1089749
can you confirm you don't have the backout that in your build that is expected to fix it? https://bugzilla.mozilla.org/show_bug.cgi?id=865314#c30
Updated•10 years ago
|
Keywords: csectype-uaf,
sec-critical
Updated•10 years ago
|
status-firefox36:
--- → affected
Updated•10 years ago
|
Whiteboard: [dupe 1089749?]
Reporter | ||
Comment 2•10 years ago
|
||
Reporter | ||
Comment 3•10 years ago
|
||
Making a comment because I don't seem to be getting bugmail for this bug ...
Assignee | ||
Comment 4•10 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #2)
> I'm on https://hg.mozilla.org/mozilla-central/rev/8230834302c9
that build does not contain the backout. So its a likely dup. Probly ok to open this up soon as it was just a one iteration nightly bug. nonetheless I'll mark it fixed rather than contaminating across security/non-security bugs with a dup. feel free to adjust if the spirit moves you.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 5•10 years ago
|
||
Can we get this confirmed that it is fixed by the backout? Otherwise, this is still an unfixed sec-critical.
QA, can you take a look at this?
Updated•10 years ago
|
Flags: needinfo?(kamiljoz)
Comment 6•10 years ago
|
||
On the assumption that this was a dupe of bug 1089749 then it was caused by bug 865314 and fixed by a backout and only affected a few days worth of Fx36 nightlies. It should be easy to confirm that with Kyle.
I'm confused by the Version being set to "32 Branch" when the bug was created. Wasn't the current release at the time and doesn't match comment 2. Bad template I guess?
Blocks: 865314
status-firefox35:
--- → unaffected
status-firefox-esr31:
--- → unaffected
Depends on: 1089749
Flags: needinfo?(khuey)
Reporter | ||
Comment 7•10 years ago
|
||
The 32 branch is some weird bugzilla thing, it's happened to me elsewhere too. I flipped the pref to disable this stuff so I haven't seen this since.
Flags: needinfo?(khuey)
Updated•10 years ago
|
Updated•10 years ago
|
Group: core-security
Updated•10 years ago
|
Flags: needinfo?(kjozwiak)
You need to log in
before you can comment on or make changes to this bug.
Description
•