830080 - crash in mozilla::net::nsHttpChannel::InitOfflineCacheEntry on LGE Nexus 4 running recent JB builds

Status: RESOLVED DUPLICATE of bug 829858

(Core :: Networking, defect)

Description

[Scoobidiver (away)]

It first showed up in 21.0a1/20130110 and on January 10.
It has been hit by four users, all on LGE Nexus 4 running recent JB builds: January 9 and above.

If it was a regression in the code, the regression range would be:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7bce868864bf&tochange=0a6e5a67c4e8

Signature 	mozilla::net::nsHttpChannel::InitOfflineCacheEntry() More Reports Search
UUID	036a67b0-4b90-4ea5-8028-8212c2130113
Date Processed	2013-01-13 00:22:41
Uptime	4
Last Crash	8 seconds before submission
Install Age	9.5 hours since version was first installed.
Install Time	2013-01-12 14:49:43
Product	FennecAndroid
Version	21.0a1
Build ID	20130112030947
Release Channel	nightly
OS	Android
OS Version	0.0.0 Linux 3.4.0-perf-g3186d08 #1 SMP PREEMPT Sat Jan 12 05:13:32 PST 2013 armv7l google/occam/mako:4.2/JOP40C/527662:user/release-keys
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x38
App Notes 	
AdapterDescription: 'Qualcomm -- Adreno (TM) 320 -- OpenGL ES 2.0 V@6.0 AU@ (CL@2946718) -- Model: Nexus 4, Product: occam, Manufacturer: LGE, Hardware: mako'
EGL? EGL+ GL Context? GL Context+ GL Layers? GL Layers+ 
LGE Nexus 4
google/occam/mako:4.2/JOP40C/527662:user/release-keys
Processor Notes 	/data/socorro/stackwalk/bin/exploitable: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	Qualcomm
Adapter Device ID	Adreno (TM) 320
Device	LGE Nexus 4
Android API Version	17 (REL)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 	libxul.so 	mozilla::net::nsHttpChannel::InitOfflineCacheEntry 	nsAutoPtr.h:124
1 	libxul.so 	mozilla::net::nsHttpChannel::CallOnStartRequest 	nsHttpChannel.cpp:981
2 	libxul.so 	mozilla::net::nsHttpChannel::ContinueOnStartRequest2 	nsHttpChannel.cpp:4901
3 	libxul.so 	mozilla::net::nsHttpChannel::OnStartRequest 	nsHttpChannel.cpp:4874
4 	libxul.so 	nsInputStreamPump::OnStateStart 	nsInputStreamPump.cpp:417
5 	libxul.so 	nsInputStreamPump::OnInputStreamReady 	nsInputStreamPump.cpp:368
6 	libxul.so 	nsInputStreamReadyEvent::Run 	nsStreamUtils.cpp:82
7 	libxul.so 	nsThread::ProcessNextEvent 	nsThread.cpp:627
8 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:238
9 	libxul.so 	mozilla::ipc::MessagePump::Run 	MessagePump.cpp:82
10 	libxul.so 	MessageLoop::RunInternal 	message_loop.cc:215
11 	libxul.so 	MessageLoop::Run 	message_loop.cc:208
12 	libxul.so 	nsBaseAppShell::Run 	nsBaseAppShell.cpp:163
13 	libxul.so 	nsAppStartup::Run 	nsAppStartup.cpp:288
14 	libxul.so 	XREMain::XRE_mainRun 	nsAppRunner.cpp:3823
15 	libxul.so 	XREMain::XRE_main 	nsAppRunner.cpp:3890
16 	libxul.so 	XRE_main 	nsAppRunner.cpp:4093
17 	libxul.so 	GeckoStart 	nsAndroidStartup.cpp:73 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Anet%3A%3AnsHttpChannel%3A%3AInitOfflineCacheEntry%28%29

Comment 1

[Scoobidiver (away)]

All crash reports have the same release key, so it's likely the same user updating its kernel every day.

Comment 2

[Honza Bambas (:mayhemer)]

It's regression from bug 761040 and a duplicate of bug 829858 that I'm just going to land.