866380 - crash in HostDB_MatchEntry on devices with amlogic hw

Status: RESOLVED FIXED

(Core :: Networking: DNS, defect)

Description

[Scoobidiver (away)]

It's #111 crasher in 20.0.1.

It occurs on (Chinese) devices with amlogic processor (see http://pdadb.net/index.php?m=cpu&id=a8726mx&c=amlogic__aml8726-mx):
MSI Enjoy 71 	4
Prestigio PMP5770D 	4
Positivo YPY_AB10D 	4
YIFANG BOULM805ND 	4
Positivo YPY_AB10DC 	3
YIFANG Next7P12-8G 	2
YIFANG PTM712MCFC 	2
YIFANG PMP5580C 	2
Positivo YPY_AB7DC 	2
MID Crystal 	1
YIFANG PTM727MCF 	1
YIFANG U2 	1
MID ELF-II 	1
MID Novo7Fire 	1
Positivo YPY_07STB 	1
YIFANG CT710 	1
COMPUMAX COMPUMAX 	1

This processor has other known issues (see bug 842936).

Signature 	HostDB_MatchEntry More Reports Search
UUID	881aecf1-856b-437d-b795-683012130426
Date Processed	2013-04-26 19:50:38
Uptime	476
Last Crash	more than 3 months before submission
Install Age	22.9 hours since version was first installed.
Install Time	2013-04-25 20:54:25
Product	FennecAndroid
Version	20.0.1
Build ID	20130410154516
Release Channel	release
OS	Android
OS Version	0.0.0 Linux 3.0.8-g242cfee #29 SMP PREEMPT Fri Oct 19 17:13:45 CST 2012 armv7l Carrefour/M755ND/M755ND:4.0.4/IMM76I/v006:user/release-keys
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x5ee00000
App Notes 	
AdapterDescription: 'ARM -- Mali-400 MP -- OpenGL ES 2.0 -- Model: CT710FR, Product: CT710FR, Manufacturer: YIFANG, Hardware: amlogic'
EGL? EGL+ GL Context? GL Context+ GL Layers? GL Layers+ 
YIFANG CT710FR
Carrefour/M755ND/M755ND:4.0.4/IMM76I/v006:user/release-keys
Processor Notes 	sp-processor02.phx1.mozilla.com_15033:2012; exploitability tool: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	ARM
Adapter Device ID	Mali-400 MP
Device	YIFANG CT710FR
Android API Version	15 (REL)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 	libc.so 	libc.so@0xe1ac 	
1 	libxul.so 	HostDB_MatchEntry 	netwerk/dns/nsHostResolver.cpp:257
2 	libxul.so 	SearchTable 	obj-firefox/xpcom/build/pldhash.cpp:402
3 	libxul.so 	PL_DHashTableOperate 	obj-firefox/xpcom/build/pldhash.cpp:624
4 	libxul.so 	nsHostResolver::ResolveHost 	netwerk/dns/nsHostResolver.cpp:538
5 	libxul.so 	nsDNSService::AsyncResolve 	netwerk/dns/nsDNSService2.cpp:638
6 	libxul.so 	nsSocketTransport::ResolveHost 	netwerk/base/src/nsSocketTransport2.cpp:931
7 	libxul.so 	nsSocketTransport::OnSocketEvent 	netwerk/base/src/nsSocketTransport2.cpp:1455
8 	libxul.so 	nsSocketEvent::Run 	netwerk/base/src/nsSocketTransport2.cpp:64
9 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
10 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:238
11 	libxul.so 	nsSocketTransportService::Run 	netwerk/base/src/nsSocketTransportService2.cpp:649
12 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
13 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:238
14 	libxul.so 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:265
15 	libnspr4.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:156
16 	libc.so 	libc.so@0x12e2e 	
17 	libc.so 	libc.so@0x12982 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=HostDB_MatchEntry

Comment 1

[Patrick McManus [:mcmanus]]

this impacts fennec

crash in libc.. probably    return !strcmp(he->rec->host, hk->host)

https://crash-stats.mozilla.com/report/index/15382b6c-1d65-4135-b986-a89cb2160219

http://hg.mozilla.org/releases/mozilla-release/annotate/394976eb6e58/netwerk/dns/nsHostResolver.cpp#l255

Comment 2

[Patrick McManus [:mcmanus]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2f373de8670a

Comment 3

[Patrick McManus [:mcmanus]]

Attachment: null check for amlogic libc implementation

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8d53524fd01d

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/8d53524fd01d

Comment 6

[Patrick McManus [:mcmanus]]

Comment on attachment 8738794 [details] [diff] [review]
null check for amlogic libc implementation

this is a crashfix for one particular handset line of fennec - a workaround for the libc on it. But within that population its a significant crash.

Approval Request Comment
[Feature/regressing bug #]: forever
[User impact if declined]: crashes continue for affected population
[Describe test coverage new/current, TreeHerder]: none
[Risks and why]: very low - its check on a libc return value for null
[String/UUID change made/needed]: none

Comment 7

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8738794 [details] [diff] [review]
null check for amlogic libc implementation

Crash fix, Aurora47+

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8738794 [details] [diff] [review]
null check for amlogic libc implementation

Let's take this fennec crash fix for beta 10. 
Patrick can you help us verify the fix once it lands?

Comment 9

[Patrick McManus [:mcmanus]]

> Patrick can you help us verify the fix once it lands?

unfortunately no - don't have the device nor a good STR. This is purely derived from crash stats data (which is pretty clear on what is happening, if not how to get there.)

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/9b649cb10e0a

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/251247ef6e66