crash [@ strlen | res_querydomainN ]

VERIFIED FIXED in Firefox 10

Status

--
critical
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: marcia, Unassigned)

Tracking

({crash, regression})

Trunk
Firefox 10
ARM
Android
crash, regression
Dependency tree / graph

Details

(crash signature)

This bug was filed from the Socorro interface and is 
report bp-9a1d92c7-f60b-4531-939c-4729f2111008 .
=============================================================

https://crash-stats.mozilla.com/report/list?signature=strlen%20|%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

Comment 1

7 years ago
It's a pretty reasonable bet that this is a regression from bug 687367.
Blocks: 687367
https://crash-stats.mozilla.com/report/index/9a1d92c7-f60b-4531-939c-4729f2111008
0 	libc.so 	strlen 	
1 	libmozutils.so 	res_querydomainN 	other-licenses/android/getaddrinfo.c:2343
2 	libmozutils.so 	_dns_getaddrinfo 	other-licenses/android/getaddrinfo.c:2229
3 	libc.so 	nsdispatch 	
4 	libmozutils.so 	__wrap_getaddrinfo 	other-licenses/android/getaddrinfo.c:764
5 	libnspr4.so 	PR_GetAddrInfoByName 	nsprpub/pr/src/misc/prnetdb.c:2079
6 	libxul.so 	nsHostResolver::ThreadFunc 	netwerk/dns/nsHostResolver.cpp:922
7 	libnspr4.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:187
8 	libc.so 	__thread_entry 	
9 	libc.so 	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: https://hg.mozilla.org/mozilla-central/rev/3a910924c50c

resolving this as fixed, please reopen if tomorrows nightlies still crash
really marking fixed
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
The backout was backed out until we can figure out which of several patches broke Android tests:
https://hg.mozilla.org/mozilla-central/rev/bcf12565b95b
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Re-landed the backout:
https://hg.mozilla.org/mozilla-central/rev/1db52ff3bfe9
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 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.
Blocks: 694325

Comment 12

7 years ago
Verified fixed: Mozilla /5.0 (Android;Linux armv7l;rv:9.0a1) Gecko/20111021 Firefox/10.0a1 Fennec/10.0a1
Device: HTC Desire
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.