830522 - crash in mozilla::dom::telephony::Telephony::RILTelephonyCallback::EnumerateCallState (plugin-container)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: General, defect)

Description

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

Attachment: decoded minidump of crash

Description of test:
1) Make an MO call
2) Send a SMS
3) Make FTP data transfer
4) End call
5) Goto 1

See on AU 172.  

Top frames:
-----------
Crash reason:  SIGSEGV
Crash address: 0xa8

Thread 0 (crashed)
 0  libxul.so!mozilla::dom::telephony::Telephony::RILTelephonyCallback::EnumerateCallState [Telephony.h : 109 + 0xe]
     r4 = 0x0000001c    r5 = 0xbeabb110    r6 = 0xbeabb110    r7 = 0xbeabb030
     r8 = 0x00000005    r9 = 0x41190fa0   r10 = 0xbeabb338    fp = 0x443a1ce0
     sp = 0xbeabafe8    lr = 0x40b7da8d    pc = 0x40819a08
    Found by: given as instruction pointer in context
 1  libxul.so!NS_InvokeByIndex_P [xptcinvoke_arm.cpp : 160 + 0x23]
     r4 = 0x408199f9    r5 = 0x00000001    r6 = 0xbeabb110    r7 = 0xbeabb030
     r8 = 0x00000005    r9 = 0x41190fa0   r10 = 0xbeabb338    fp = 0x443a1ce0
     sp = 0xbeabb000    pc = 0x40b7da8d
    Found by: call frame info
 2  libxul.so!XPCWrappedNative::CallMethod [XPCWrappedNative.cpp : 3083 + 0xd]
     r4 = 0xbeabb110    r5 = 0xbeabb0a8    r6 = 0x00000020    r7 = 0x00000005
     r8 = 0x0000000a    r9 = 0x41190fa0   r10 = 0xbeabb338    fp = 0x41410890
     sp = 0xbeabb060    pc = 0x408db133
    Found by: call frame info

Comment 1

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

Attachment: logcat captured during this run

Comment 2

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Hi Michael,

Regarding Step3, did you mean sending/receiving a file via busybox ftp utilities in adb shell?

Comment 3

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

Yes, outside of the normal UI.

Comment 4

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

I've done some tests and can reproduce the crash of Dialer app following Michael's steps. Though, I never got the same backtrace and crash reason so far.

The crash points and reasons I encountered varied. See followings:
=================================
#1 gdb-log

prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin/arm-linux-androideabi-gdb -x /tmp/b2g.gdbinit.hsinyi /home/hsinyi/WorkSpace/mozilla/B2G-otoro/objdir-gecko/dist/bin/plugin-container
GNU gdb (GDB) 7.1-android-gg2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-linux-gnu --target=arm-elf-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/hsinyi/WorkSpace/mozilla/B2G-otoro/objdir-gecko/dist/bin/plugin-container...done.
Remote debugging from host 127.0.0.1

syscall () at bionic/libc/arch-arm/bionic/syscall.S:50
50	    ldmfd   sp!, {r4, r5, r6, r7}
(gdb) c
Continuing.


Child terminated with signal = 0x9 (SIGKILL)


Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) bt
No stack.
================================================
#2 gdb-log

Program received signal SIGTERM, Terminated.
0x400c97f8 in arena_dalloc (ptr=0x44ac2110, offset=794896) at /home/hsinyi/WorkSpace/mozilla/B2G-otoro/gecko/memory/mozjemalloc/jemalloc.c:4663
4663		mapelm = &chunk->map[pageind];
(gdb) bt
#0  0x400c97f8 in arena_dalloc (ptr=0x44ac2110, offset=794896) at /home/hsinyi/WorkSpace/mozilla/B2G-otoro/gecko/memory/mozjemalloc/jemalloc.c:4663
Cannot access memory at address 0xbecaad1c
============================================
#3 gdb-log

Program received signal SIGTERM, Terminated.
arena_run_dalloc (arena=0x4226f040, run=<value optimized out>, dirty=<value optimized out>) at /home/hsinyi/WorkSpace/mozilla/B2G-otoro/gecko/memory/mozjemalloc/jemalloc.c:3767
3767		if (run_ind + run_pages < chunk_npages &&
(gdb) bt
#0  arena_run_dalloc (arena=0x4226f040, run=<value optimized out>, dirty=<value optimized out>) at /home/hsinyi/WorkSpace/mozilla/B2G-otoro/gecko/memory/mozjemalloc/jemalloc.c:3767
Cannot access memory at address 0xbe882bc4
=============================================
#4 gdb-log

Program received signal SIGTERM, Terminated.
write () at bionic/libc/arch-arm/syscalls/write.S:10
10	    ldmfd   sp!, {r4, r7}
(gdb) bt
#0  write () at bionic/libc/arch-arm/syscalls/write.S:10
Cannot access memory at address 0x400dc588
(gdb) l
5	ENTRY(write)
6	    .save   {r4, r7}
7	    stmfd   sp!, {r4, r7}
8	    ldr     r7, =__NR_write
9	    swi     #0
10	    ldmfd   sp!, {r4, r7}
11	    movs    r0, r0
12	    bxpl    lr
13	    b       __set_syscall_errno
14	END(write)

Comment 5

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Attachment: gdb bt - when b2g process sends sigkill to dialer app

Comment 6

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Not found the root cause yet, marked LOE:M temporarily.

Comment 7

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

After I updated unagi to 01/15 engineering version, all I got is 'Child terminated with signal = 0x9 (SIGKILL)' in gdb dump of Dialer app. In the mean while, I was seeing the 'dmesg' 
  <4>[01-16 08:13:32.994] [28: kswapd0]select 18351 (Communications), adj 6, size 6777, to kill
I think this crash results from OOM. 

To reproduce of this, we don't actually need making FTP connection. Just 1) make a call by Dialer, and leave the call connected. 2) Then switch to the message app, sending SMS. 3) Back to Dialer to end the call. After several run, you will see the Dialer being killed.

Test version:
gecko - git, gecko-18 branch, 8ab9f170185b31cc7b4d042eef59088e5901645d (Jan. 15)
gaia - git, master branch, 03afcdba94d3ca21f57f889d83bde15b2f37e236 (Jan. 15)

Comment 8

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Oops, sorry, I didn't mean to change the tef+ flag.

Comment 9

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Following the steps in comment 7, not only dialer app got killed but also homescreen app (very often) and message app (seldom).

Comment 10

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

I would say this is an OOM issue. Should we make it to 'tef-' ?

Comment 11

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

Why would we not fix an OOM issue?

Comment 12

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The SIGTERM's in comment 4 are concerning.  That happens either when an app shuts down, or it does something wrong and the master process kills it.  Were there any messages in logcat?

For the steps in comment 7, is the dialer being killed while a call is active, or when it's in the foreground?

Comment 13

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> The SIGTERM's in comment 4 are concerning.  That happens either when an app
> shuts down, or it does something wrong and the master process kills it. 
> Were there any messages in logcat?
> 
> For the steps in comment 7, is the dialer being killed while a call is
> active, or when it's in the foreground?

The dialer is killed while a call is disconnected but the app is in the foreground.

Comment 14

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Can you try running

$ while true; do adb shell b2g-ps --oom | grep Comm; sleep 0.25; done

while you reproduce this and see what the last oom_adj value for the dialer is when it dies?  (Second column in the output.)

Comment 15

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Attachment: logcat - MsgValueError

Comment 16

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> The SIGTERM's in comment 4 are concerning.  That happens either when an app
> shuts down, or it does something wrong and the master process kills it. 
> Were there any messages in logcat?
> 
In attachment 702200 [details], there's an ipc message error 'MsgValueError'. The ipc message name was 'PNecko::Msg_PRemoteOpenFileConstructor'. 

In logcat (attachment 702721 [details]):
17068 I/Gecko   (  105): NeckoParent::AllocPRemoteOpenFile: FATAL error: missing TabParent: KILLING CHILD PROCESS
17069 I/Gecko   (  105):
17070 I/Gecko   (  105): ###!!! [Parent][AsyncChannel] Error: Value error: message was deserialized, but contained an illegal value

> For the steps in comment 7, is the dialer being killed while a call is
> active, or when it's in the foreground?

Comment 17

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #14)
> Can you try running
> 
> $ while true; do adb shell b2g-ps --oom | grep Comm; sleep 0.25; done
> 
> while you reproduce this and see what the last oom_adj value for the dialer
> is when it dies?  (Second column in the output.)

Hi cjones,  

It's 6. Last out:
|Communications       6        554         400        app_6574  6574  108   80240  29588 ffffffff 41681514 R /system/b2g/plugin-container|

Comment 18

[Patrick Wang (Chih-Kai Wang) (:kk1fff)]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #16)
> In attachment 702200 [details], there's an ipc message error
> 'MsgValueError'. The ipc message name was
> 'PNecko::Msg_PRemoteOpenFileConstructor'. 
> 
> In logcat (attachment 702721 [details]):
> 17068 I/Gecko   (  105): NeckoParent::AllocPRemoteOpenFile: FATAL error:
> missing TabParent: KILLING CHILD PROCESS
> 17069 I/Gecko   (  105):
> 17070 I/Gecko   (  105): ###!!! [Parent][AsyncChannel] Error: Value error:
> message was deserialized, but contained an illegal value
> 

Could this be related the case that is mentioned in bug 824677 comment 36?

Comment 19

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #17)
> It's 6. Last out:
> |Communications       6        554         400        app_6574  6574  108  
> 80240  29588 ffffffff 41681514 R /system/b2g/plugin-container|

This is the background OOM class.  This is a gaia bug.

Comment 20

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to Patrick Wang [:kk1fff] from comment #18)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #16)
> > In attachment 702200 [details], there's an ipc message error
> > 'MsgValueError'. The ipc message name was
> > 'PNecko::Msg_PRemoteOpenFileConstructor'. 
> > 
> > In logcat (attachment 702721 [details]):
> > 17068 I/Gecko   (  105): NeckoParent::AllocPRemoteOpenFile: FATAL error:
> > missing TabParent: KILLING CHILD PROCESS
> > 17069 I/Gecko   (  105):
> > 17070 I/Gecko   (  105): ###!!! [Parent][AsyncChannel] Error: Value error:
> > message was deserialized, but contained an illegal value
> > 
> 
> Could this be related the case that is mentioned in bug 824677 comment 36?

This is a different error message, so I don't think so.

Comment 21

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #20)
> (In reply to Patrick Wang [:kk1fff] from comment #18)
> > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #16)
> > > In attachment 702200 [details], there's an ipc message error
> > > 'MsgValueError'. The ipc message name was
> > > 'PNecko::Msg_PRemoteOpenFileConstructor'. 
> > > 
> > > In logcat (attachment 702721 [details]):
> > > 17068 I/Gecko   (  105): NeckoParent::AllocPRemoteOpenFile: FATAL error:
> > > missing TabParent: KILLING CHILD PROCESS
> > > 17069 I/Gecko   (  105):
> > > 17070 I/Gecko   (  105): ###!!! [Parent][AsyncChannel] Error: Value error:
> > > message was deserialized, but contained an illegal value
> > > 
> > 
> > Could this be related the case that is mentioned in bug 824677 comment 36?
> 
> This is a different error message, so I don't think so.

I am trying hard to reproduce this error message, but couldn't make it after updating my device today. Unfortunately, I have no idea about the gecko commit Ｉ tested yesterday...

Comment 22

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

So we have three bugs here, it seems

 1. The communications process has background priority while it's in the foreground.  This explains the lmk death.  Gaia bug.

 2. The NeckoParent error.  No idea about this one.

 3. The crash reported here.  Seems like it might be related to (2).

Comment 23

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #22)
> So we have three bugs here, it seems
> 
>  1. The communications process has background priority while it's in the
> foreground.  This explains the lmk death.  Gaia bug.
> 
I just confirmed with gaia developers. I was told that in my reproducing steps, the dialer app remained background because I only made the call screen, individual iframe, become foreground when I touched the end-call button. That is, the dialer app itself stayed background. #1 seems invalid since the dialer app with the lower priority when it was killed. Sorry for any confusion.

>  2. The NeckoParent error.  No idea about this one.
> 
>  3. The crash reported here.  Seems like it might be related to (2).

Comment 24

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The green in-call status bar at the top of the screen is visible UI for the dialer, so it needs to stay foreground.  Etienne fixed a bug in which that wasn't happening.

The in-call screen is also part of the dialer UI, so if tapping the green bar to bring that screen moves the dialer into the background, that's a bug.

Comment 25

[Etienne Segonzac (:etienne)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #24)
> The green in-call status bar at the top of the screen is visible UI for the
> dialer, so it needs to stay foreground.  Etienne fixed a bug in which that
> wasn't happening.


From the homescreen, receiving an incoming call:
- the call screen iframe is properly set visible (mozHidden == false)
- the Communications app "main" iframe stays mozHidden == true, because, well, we're not showing it
- the OOM_ADJ of the Communications app is 6

I don't know when we bump the score to 1, but the Communications app has many potential iframes (Dialer entry point, Contacts entry point, Call screen attention screen) so it's pretty edgy.

Comment 26

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Is the call screen a top-level |window|?

Comment 27

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Hi Hsin-Yi,

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)
> To reproduce of this, we don't actually need making FTP connection. Just 1)
> make a call by Dialer, and leave the call connected. 2) Then switch to the
> message app, sending SMS. 3) Back to Dialer to end the call. After several
> run, you will see the Dialer being killed.

I wasn't able to reproduce this with a "user" build made from 

$ (cd gecko/ && git rev-parse HEAD && cd ../gaia && git rev-parse HEAD)
2751cf873c70a03933c407d3bc06003e72c7fbc3
3c84fa2b74b3dbe591f0d4fbedbac9aac5ca4654

The steps I followed were exactly
 (1) Launch dialer app
 (2) Place call to number
 (3) Launch SMS app
 (4) Send SMS to number
 (5) Tap green in-call status bar to open call screen
 (6) Tap red "hangup" button
 (7) Press HOME
 (8) Goto (1)

I ran through 10 iterations and gave up.

In addition to the dialer and SMS app, there were 6 other apps open in the background the whole time I ran this test.

Is there something I should do differently?

Comment 28

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #27)
> Hi Hsin-Yi,
> 
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #7)
> > To reproduce of this, we don't actually need making FTP connection. Just 1)
> > make a call by Dialer, and leave the call connected. 2) Then switch to the
> > message app, sending SMS. 3) Back to Dialer to end the call. After several
> > run, you will see the Dialer being killed.
> 
> I wasn't able to reproduce this with a "user" build made from 
> 
> $ (cd gecko/ && git rev-parse HEAD && cd ../gaia && git rev-parse HEAD)
> 2751cf873c70a03933c407d3bc06003e72c7fbc3
> 3c84fa2b74b3dbe591f0d4fbedbac9aac5ca4654
> 
> The steps I followed were exactly
>  (1) Launch dialer app
>  (2) Place call to number
>  (3) Launch SMS app
>  (4) Send SMS to number
>  (5) Tap green in-call status bar to open call screen
>  (6) Tap red "hangup" button
>  (7) Press HOME
>  (8) Goto (1)
> 
> I ran through 10 iterations and gave up.
> 
> In addition to the dialer and SMS app, there were 6 other apps open in the
> background the whole time I ran this test.
> 
> Is there something I should do differently?

Main difference could be that I enabled B2G_DEBUG=1 :\ Hardly reproduce this with B2G_DEBUG=0, it happened once after tens of iteration though.

NeckoParent error showed up again after tens, tens, tens of iteration... Any insights here?

Comment 29

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

Sorry, not quite sure what the ni? here is for.  But I just checked and  we haven't seen this crash since AU 172 (1/10) so maybe "mystery fix"

Comment 30

[Andrew Overholt [:overholt]]

(In reply to Michael Vines [:m1] from comment #29)
> Sorry, not quite sure what the ni? here is for.  But I just checked and  we
> haven't seen this crash since AU 172 (1/10) so maybe "mystery fix"

Sorry, should have provided context.  But it looks like it wasn't necessary :)

Resolving but please re-open if this re-occurs.

Comment 31

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Michael Vines [:m1] from comment #29)
> Sorry, not quite sure what the ni? here is for.  But I just checked and  we
> haven't seen this crash since AU 172 (1/10) so maybe "mystery fix"

I investigated attachment 701996 [details] again and found a weird message, line#27028.
|-*- QCContentHelper_QC_B2G: sendMessage to content process: RIL:CallStateChanged{  state : 10,callIndex : -1,toa : ... ... |

The callIndex should be 1, not -1, in the context, but I doubt this is the cause of the crash originally reported since the crash didn't happen even I added some buggy test code to send this weird message in moz ril. The test result was a call object being hung on in DOM as expected, according to the DOM implementation. 

Just complement of what I found. Nothing affected the issue's status. :)

Comment 32

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

Opps, Anshul might comment 31 still happen at the tip?  Unrelated to this bug it seems but something to fix regardless.

Comment 33

[Anshul]

There are no radio logs to confirm but it seems like the call was disconnected while dialing before RIL got a chance to respond to it. The index of -1 is expected in this case and should not be a reason for the issue reported in this bug.

There are other cases like the one at "http://mxr.mozilla.org/mozilla-aurora/source/dom/system/gonk/ril_worker.js#1525" where callindex is set to -1.

Comment 34

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Anshul from comment #33)
> There are no radio logs to confirm but it seems like the call was
> disconnected while dialing before RIL got a chance to respond to it. The
> index of -1 is expected in this case and should not be a reason for the
> issue reported in this bug.
> 
> There are other cases like the one at
> "http://mxr.mozilla.org/mozilla-aurora/source/dom/system/gonk/ril_worker.
> js#1525" where callindex is set to -1.
If the callindex was set to -1 in this line, then the message type should be "RIL:CallError" instead of "RIL:CallStateChanged".

In the attachment Michael provided, I can see the outgoing call state was changed from 'dialing (state 1)', to 'alerting (state 2)', 'connected (state 5)', finally got 'disconnected (state 10). Since this is the log of qc ril, I may misunderstand or miss something ;) I am also thinking that this issue may not be the cause of the original report but who knows, especially while this message showed almost at the end of the crash run (if the attachment recorded all messages during that test run). Just provide my finding for your reference :)

Comment 35

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

This crash is back on AU 185.

Comment 36

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

Attachment: decoded minidump of crash from AU 185

Comment 37

[Jason Duell]

> > NeckoParent::AllocPRemoteOpenFile: FATAL error:
> > missing TabParent: KILLING CHILD PROCESS
>
> 2. The NeckoParent error.  No idea about this one.

This means that something in the child tried to open an app:// URI but called asyncOpen on the app channel (really a JARChannel under the covers) without setting channel callbacks that implement TabChild/PBrowserChild, which is needed for IPDL security.  That child process then gets killed by the parent.

This is either because 1) there's a codepath where setting that info is missing, or 2) you hit bug 833935, where we were seeing null because we sometimes launch channels while the containing page is already shut down during page navigation (fixed as of this morning, unless you use a debug build, where we've made the child abort, for now at least).  Seems odd to be launching app:// during an onclose() function, etc, so probably #1?

See bug 782542 for context and bug 823962 and bug 824200 for other cases where we were missing Tabchild and fixed it.

Oh, also note that app:// URIs from "core" apps (those that aren't removable IIUC) don't take this codepatch (they open JAR files directly on child because they have I/O permission to do so). So if the dialer is a core app, then the "AllocPRemoteOpenFile: FATAL error" is killing some other app than the dialer.  I should really write a patch to printf the app:// URI in that log message...

Comment 38

[Anshul]

This might be an issue with commercial RIL. Will reopen if we see the issue again.

Comment 39

[Anshul]

Hsin-Yi, the crash came back in AU 189 even after fixing the callIndex: -1 issue you pointed out earlier. Please find the top of call stack below and the complete minidump attached.

Crash reason:  SIGSEGV
Crash address: 0x8c

Thread 0 (crashed)
 0  libxul.so!mozilla::dom::telephony::Telephony::RILTelephonyCallback::EnumerateCallState [Telephony.h : 109 + 0xe]
     r4 = 0x00000000    r5 = 0xbecee100    r6 = 0xbecee100    r7 = 0xbecee020
     r8 = 0x00000005    r9 = 0x412274c8   r10 = 0xbecee328    fp = 0x43765ea0
     sp = 0xbecedfd8    lr = 0x40bff915    pc = 0x4087cb60
    Found by: given as instruction pointer in context
 1  libxul.so!NS_InvokeByIndex_P [xptcinvoke_arm.cpp : 160 + 0x23]
     r4 = 0x4087cb51    r5 = 0x00000001    r6 = 0xbecee100    r7 = 0xbecee020
     r8 = 0x00000005    r9 = 0x412274c8   r10 = 0xbecee328    fp = 0x43765ea0
     sp = 0xbecedff0    pc = 0x40bff915
    Found by: call frame info

Comment 40

[Anshul]

Attachment: decoded minidump of crash from AU 189

Comment 41

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Anshul,

Sadly this happened again. To further investigate this issue, we need more information from you. Would you please help provide us the following?
1) complete logcat of the test run
2) RIL binary code of the test image
3) code version you were testing with
4) better with the detailed test steps

We do need them for debugging and resolving this issue. Thank you.

Comment 42

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

I will change the bug summary back to Michael's original report. I filed another bug 832098 for NeckoParent error mentioned in comment 16.

Comment 43

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #42)
> I will change the bug summary back to Michael's original report. I filed
> another bug 832098 for NeckoParent error mentioned in comment 16.
          ^^^^^^^^^^  Oops... should be bug 832908

Comment 44

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Attachment: WIP

Make sure we unregister enumerationTelephonyCallback

Comment 45

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Comment on attachment 708426 [details] [diff] [review]
WIP

Hi Anshul,

After reviewing the code, we conjectured this patch might address the cause of the crash. But since we still cannot reproduce the problem, we'd like to ask you to help us test this patch, to see if we got the right direction and if it works. Thank you :)

Comment 46

[Anshul]

Hsin-Yi, please find the information you requested.

- Log file attached
- You can get the RIL binary from AU 189
- Steps to reproduce
  - Make incoming calls
  - Run music in background
  - Repeat above steps

The crash happened after the above test case was run over night by our stability team.

I can pull in the patch in our build and have stability team run an overnight test but this is not 100% reproducible. Wondering if you could just land the patch if you think that the patch fixes the issue. I can then update you once the change lands in our tree and stability test has been run.

Comment 47

[Anshul]

Attachment: Android logs from AU 189

Comment 48

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Anshul from comment #47)
> Created attachment 708431 [details]
> Android logs from AU 189

The pid of b2g is 127 throughout the log. Can you provide some more details about the "crash"? Is there a crash at all?

Comment 49

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

Crash happens in the communications app, not the main process.

Comment 50

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/987ebceef054

Comment 51

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Attachment: patch for b2g18: unregister enumerationTelephonyCallback. r=vicamo

revised code comments

Comment 52

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #51)
> Created attachment 708513 [details] [diff] [review]
> unregister enumerationTelephonyCallback. r=vicamo
> 
> revised code comments

This is the patch for pushing into *b2g-18* branch. Thanks!

Comment 53

[Anshul]

Hsin-Yi, will this patch be available in b2g-18_v1.0.0?

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/987ebceef054

Comment 55

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/987ebceef054

Comment 56

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/152156c3ddda
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_0/rev/9591cb0b7249

Comment 57

[amiller]

Does not make sense to create a regression issue.

Comment 58

[Chris Kreinbring [:CKreinbring]]

Verified in both 1.0.1 and 1.1 builds.  Multiple attempts were made to crash the device by making calls to the device while the device was playing music in the background.  Also sent SMS messages just before the call was received but that didn't cause any crashes.

1.0.1:
Unagi build 20130403070201
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/512258bc00a3
Gaia: daea430624ec02f8d36a12d581fc4a3278c27cb7

1.1:
Unagi build 20130403070204
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/d467369d1b0c
Gaia: 06e0e5ce42bdfb62bdbe38271de6b5b2d9e40e75