851812 - crash in nsThread::ProcessNextEvent @ libqc_b2g_ril

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Scoobidiver (away)]

Here is a crash report: bp-f4c857db-62e1-4426-a27f-92a9a2130315.

Frame 	Module 	Signature 	Source
0 	libqc_b2g_ril.so 	libqc_b2g_ril.so@0x39e9a 	
1 	b2g 	MOZ_PNG_do_read_trans 	pngrtran.c:2132
2 		@0x3 	
3 	libnspr4.so 	PR_Unlock 	ptsynch.c:205
4 	libnspr4.so 	PR_ExitMonitor 	ptsynch.c:557
5 	libxul.so 	nsEventQueue::GetEvent 	ReentrantMonitor.h:80
6 		@0xffffffff 	
7 	libqc_b2g_ril.so 	libqc_b2g_ril.so@0x2cdaf 	
8 	libxul.so 	nsThread::ProcessNextEvent 	nsThread.cpp:620
9 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:237
10 	libxul.so 	mozilla::ipc::MessagePump::Run 	MessagePump.cpp:82
11 	libxul.so 	MessageLoop::RunInternal 	message_loop.cc:216
12 	libxul.so 	MessageLoop::Run 	message_loop.cc:209
13 	libxul.so 	nsBaseAppShell::Run 	nsBaseAppShell.cpp:163
14 	libxul.so 	nsAppStartup::Run 	nsAppStartup.cpp:290
15 	libxul.so 	XREMain::XRE_mainRun 	nsAppRunner.cpp:3794
16 	libxul.so 	XREMain::XRE_main 	nsAppRunner.cpp:3860
17 	libxul.so 	XRE_main 	nsAppRunner.cpp:3935
18 	b2g 	main 	nsBrowserApp.cpp:168
19 	libc.so 	__libc_init 	libc_init_dynamic.c:114
20 	libc.so 	__cxa_atexit 	atexit.c:99
21 		@0xbeda3d45 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=libqc_b2g_ril.so%400x39e9a
https://crash-stats.mozilla.com/report/list?signature=libqc_b2g_ril.so%400x35f70

Comment 1

[Michael Vines [:m1] [:evilmachines]]

I bet this is a dup of 851366

Comment 2

[Michael Vines [:m1] [:evilmachines]]

Build ID for this crash is 20130315070220.  How do I determine what version of the RIL was picked up for this build by Mozilla?

Comment 3

[Tony Chung [:tchung]]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #2)
> Build ID for this crash is 20130315070220.  How do I determine what version
> of the RIL was picked up for this build by Mozilla?

likely ril01.00.01.19.041.zip.

Comment 4

[Michael Vines [:m1] [:evilmachines]]

Thanks.   Yeah this is almost certainly due to the RIL interface change that is being discussed in bug 851366.

AU 01.00.01.19.041 is only validated against moz build ID 20130314115057 [1].



[1] https://www.codeaurora.org/gitweb/quic/b2g/?p=b2g/manifest.git;a=blob;f=caf_AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.19.041.xml;h=ee47195b359afef6484a41c909181f3fab4e0833;hb=4e901e487e33731fa89edf7731c87104e21b77ef#l3

Comment 5

[Scoobidiver (away)]

Bug 851366 is considered fixed but no this one.

Comment 7

[Scoobidiver (away)]

(Naoki Hirata :nhirata (please use needinfo instead of cc) from bug 859915 comment #0 wrote)
> 1) flashed the latest ril build : 	unagi-20130409070205-ril01.01.00.19.059
> 2) go through the FTU to network [entered pin as SIM is locked; did not set
> mobile data]
> 3) quickly selected an open network and before the wifi was set, select the
> next button.

Comment 9

[Gabriele Svelto [:gsvelto]]

I'm having a hard time reproducing this crash. I flashed my Unagi with this build as per comment 7:

https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/2013/04/2013-04-09-07-02-05/unagi.zip

I've locked my SIM in and made an open wifi network available in order to have the same conditions so what I do is the following:

- reset the phone so that it will start the FTU from a clean state
- go through the FTU, unlock the SIM, do not enable data
- once in the wifi screen I select the open and network and quickly tap the next button

I have tried six times already but couldn't get it to crash. I'm I using the correct build and procedure to reproduce this or am I missing something?

Comment 10

[Gabriele Svelto [:gsvelto]]

I realized that in my previous testing I wasn't using the proper build to reproduce this. Today I flashed the unagi-20130409070205-ril01.01.00.19.059.zip build mentioned in comment 7 and re-tested thoroughly. I run the STR ten times resetting the phone in-between each run but couldn't reproduce the issue. Is it possible that this might depend on the carrier or some other external factor? I'm using a Dutch Lebara SIM for testing and the network is an open 802.11n wifi network.

Comment 11

[Michael Vines [:m1] [:evilmachines]]

I think we are wasting our time here.  IMO, WONTFIX unless this is reproduced with gecko/gaia SHA1s that match those in the latest AU.

Comment 12

[Gabriele Svelto [:gsvelto]]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #11)
> I think we are wasting our time here.  IMO, WONTFIX unless this is
> reproduced with gecko/gaia SHA1s that match those in the latest AU.

I'm not very familiar with this interface but from what I can tell the contract hash for the latest AU (01.00.01.019.107) is @mozilla.org/ril;1 {9A7181E8-E66A-11E1-B4A1-B1066188709B}

Comment 13

[Gabriele Svelto [:gsvelto]]

Looking at the history of dom/system/b2g/RadioInterfaceLayer.manifest the hash number above never appeared. The current version in mozilla-central is @mozilla.org/ril;1 {2d831c8d-6017-435b-a80c-e5d422810cea}

Comment 14

[Gabriele Svelto [:gsvelto]]

OK, after much delving into our nightly builds I found version with buildid 20130314115057 and AU 01.00.01.19.041 and tried to reproduce the problem. I applied the STR ten times resetting the phone after every try and never succeeded in reproducing the problem so I'll close this as WONTFIX as per comment 11.

Comment 15

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Ya, I think it may have been a RIL mismatch or something funky like that.  I am comfortable with the Won't fix, as I haven't ran into this situation again.  There's a patch that mvines did to failover to the mozril that may help with this from occurring again.