Closed Bug 693103 Opened 14 years ago Closed 14 years ago

crash [@ strlen | res_querydomainN ]

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Firefox 10

People

(Reporter: marcia, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

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
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?
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
Closed: 14 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
Closed: 14 years ago → 14 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
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.