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)
Note that it doesn't show up in crash stats, at least in the trunk.
Severity: normal → critical
Hardware: All → ARM
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)
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
OS: Android → All
Hardware: ARM → All
mats - awesome. nick, you want to give this one a look?
Component: Networking → Networking: HTTP
Whiteboard: [native-crash] → [native-crash] [spdy]
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).
we're going to resolve this under the 865314 backout
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.