835384 - Crash with abort message "###!!! ABORT: AddStream duplicate transaction pointer: '!mStreamTransactionHash.Get(aHttpTransaction)'

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

I don't have specific STR for this but sometimes when loading a page on my Galaxy Nexus Fennec debug build it will crash and I see this in logcat:

01-28 11:24:45.441 I/Gecko   (21631): void mozilla::AndroidBridge::HandleGeckoMessage(const nsAString_internal&, nsAString_internal&)
01-28 11:24:45.441 I/Gecko   (21631): leaving void mozilla::AndroidBridge::HandleGeckoMessage(const nsAString_internal&, nsAString_internal&)
01-28 11:24:45.925 I/Gecko   (21631): WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004003: file /Users/kats/zspace/mozilla-git/intl/uconv/src/nsCharsetConverterManager.cpp, line 301
01-28 11:24:46.112 I/Gecko   (21631): ###!!! ABORT: AddStream duplicate transaction pointer: '!mStreamTransactionHash.Get(aHttpTransaction)', file /Users/kats/zspace/mozilla-git/netwerk/protocol/http/SpdySession3.cpp, line 307
01-28 11:24:46.112 E/Gecko   (21631): mozalloc_abort: ###!!! ABORT: AddStream duplicate transaction pointer: '!mStreamTransactionHash.Get(aHttpTransaction)', file /Users/kats/zspace/mozilla-git/netwerk/protocol/http/SpdySession3.cpp, line 307
01-28 11:24:46.112 F/libc    (21631): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 21660 (Socket Thread)

Comment 1

[Scoobidiver (away)]

Note that it doesn't show up in crash stats, at least in the trunk.

Comment 2

[Patrick McManus [:mcmanus]]

Its a debug mode only intentional crash - there is runtime handling for the same situation in non debug builds; so its probably not severity critical. (It is on my list of things to look at)

Comment 3

[Mats Palmgren (inactive)]

Attachment: stack

Comment 4

[Mats Palmgren (inactive)]

It's reproducible in a FF trunk debug build on Linux64:
1. start Firefox using a fresh profile
2. close the "first run page" (the tab on the left) as soon as that page
   starts to render, but before it's fully loaded
3. immediately after that, quit the application

Comment 5

[Patrick McManus [:mcmanus]]

mats - awesome. nick, you want to give this one a look?

Comment 6

[u408661]

I have not been able to reproduce this following the steps from comment 4 ... I have a sneaking suspicion that the reproducibility was caused by the same thing that caused crashes in CleanupStream (namely the landing of bug 865314, which has since been backed out).

Comment 7

[Patrick McManus [:mcmanus]]

we're going to resolve this under the 865314 backout