crash [@ strlen | res_querydomainN ]

VERIFIED FIXED in Firefox 10


8 years ago
8 years ago


(Reporter: marcia, Unassigned)


({crash, regression})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(crash signature)

This bug was filed from the Socorro interface and is 
report bp-9a1d92c7-f60b-4531-939c-4729f2111008 .
=============================================================|%20res_querydomainN to all the crashes which seemed to start with the 20111007 build 

I hit this crash on my HTC Evo phone several times this morning using the 20111007 build and can reproduce it with today's nightly as well.

I think the STR are:

1. Load the nightly and browse to a website
2. The page starts to load
3. Suddenly I get the HTC Sense UI interrupting
4. Then I crash
It's a pretty reasonable bet that this is a regression from bug 687367.
Blocks: 687367
0 	strlen 	
1 	res_querydomainN 	other-licenses/android/getaddrinfo.c:2343
2 	_dns_getaddrinfo 	other-licenses/android/getaddrinfo.c:2229
3 	nsdispatch 	
4 	__wrap_getaddrinfo 	other-licenses/android/getaddrinfo.c:764
5 	PR_GetAddrInfoByName 	nsprpub/pr/src/misc/prnetdb.c:2079
6 	nsHostResolver::ThreadFunc 	netwerk/dns/nsHostResolver.cpp:922
7 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:187
8 	__thread_entry 	
9 	pthread_create
This is already our #2 crasher. Do we backout bug 687367 until we get a fix for this?
Duplicate of this bug: 693277
This is now the #1 crasher on 10.0a1

It is 30% of all 10.0a1 crashes. Let's backout bug 687367
already backed it out:

resolving this as fixed, please reopen if tomorrows nightlies still crash
really marking fixed
Closed: 8 years ago
Resolution: --- → FIXED
The backout was backed out until we can figure out which of several patches broke Android tests:
Resolution: FIXED → ---
Re-landed the backout:
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 10
Crash Signature: [@ strlen | res_querydomainN] → [@ strlen | res_querydomainN] [@ strlen | res_querydomainN ]
Summary: crash strlen → crash [@ strlen | res_querydomainN ]
It looks to me like this can only happen if a bad "name" pointer arrives at the name resolution thread's dispatch loop, or if it gets corrupted later in the call chain.  Looking at the values of the segfaulted pointer in the crash reports, I see no particular pattern other than the presence of a number of small integers -- suggesting to me that a name resolution request has been sent from a thread on one core to a thread on another, and the receiving thread sees stale data in the call parameters, possibly due to a missing memory barrier.  Can anyone come up with a less exotic explanation?
A less exotic explanation has been suggested.  See bug 687367 for more.
Verified fixed: Mozilla /5.0 (Android;Linux armv7l;rv:9.0a1) Gecko/20111021 Firefox/10.0a1 Fennec/10.0a1
Device: HTC Desire
You need to log in before you can comment on or make changes to this bug.