Closed Bug 830522 Opened 7 years ago Closed 7 years ago

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

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:tef+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 verified, b2g18-v1.0.0 fixed, b2g18-v1.0.1 verified)

VERIFIED FIXED
B2G C4 (2jan on)
blocking-b2g tef+
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 --- verified
b2g18-v1.0.0 --- fixed
b2g18-v1.0.1 --- verified

People

(Reporter: m1, Assigned: hsinyi)

References

Details

(Whiteboard: [cr 440761] [LOE:M][triage:1/16])

Attachments

(8 files, 1 obsolete file)

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
Whiteboard: [cr 440761]
Assignee: nobody → htsai
Hi Michael,

Regarding Step3, did you mean sending/receiving a file via busybox ftp utilities in adb shell?
Yes, outside of the normal UI.
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)
Not found the root cause yet, marked LOE:M temporarily.
Whiteboard: [cr 440761] → [cr 440761] [LOE:M]
blocking-b2g: tef? → tef+
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)
blocking-b2g: tef+ → tef?
Oops, sorry, I didn't mean to change the tef+ flag.
Following the steps in comment 7, not only dialer app got killed but also homescreen app (very often) and message app (seldom).
Summary: crash in mozilla::dom::telephony::Telephony::RILTelephonyCallback::EnumerateCallState (plugin-container) → [Homescreen] [ Dialer] [ Message] got killed when we leave dialer app open with a connected call, then switch to Message app to send SMS, finally go back to Dialer app to release the call
I would say this is an OOM issue. Should we make it to 'tef-' ?
Blocks: slim-fast
Why would we not fix an OOM issue?
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?
blocking-b2g: tef? → tef+
(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.
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.)
Attached file logcat - MsgValueError
(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?
(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|
(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?
(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.
(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.
(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 I tested yesterday...
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).
(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).
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.
(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.
Is the call screen a top-level |window|?
Whiteboard: [cr 440761] [LOE:M] → [cr 440761] [LOE:M][triage:1/16]
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?
(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?
Flags: needinfo?(mvines)
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"
Flags: needinfo?(mvines)
(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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
(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. :)
Opps, Anshul might comment 31 still happen at the tip?  Unrelated to this bug it seems but something to fix regardless.
Flags: needinfo?(anshulj)
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.
Flags: needinfo?(anshulj)
(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 :)
This crash is back on AU 185.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
> > 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...
This might be an issue with commercial RIL. Will reopen if we see the issue again.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → INVALID
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
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
Flags: needinfo?(anshulj)
I will change the bug summary back to Michael's original report. I filed another bug 832098 for NeckoParent error mentioned in comment 16.
Summary: [Homescreen] [ Dialer] [ Message] got killed when we leave dialer app open with a connected call, then switch to Message app to send SMS, finally go back to Dialer app to release the call → crash in mozilla::dom::telephony::Telephony::RILTelephonyCallback::EnumerateCallState (plugin-container)
(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
Attached patch WIP (obsolete) — Splinter Review
Make sure we unregister enumerationTelephonyCallback
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 :)
Attachment #708426 - Flags: feedback?(anshulj)
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.
Flags: needinfo?(anshulj)
(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?
Attachment #708426 - Flags: feedback?(anshulj) → review+
Crash happens in the communications app, not the main process.
revised code comments
Attachment #708426 - Attachment is obsolete: true
(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!
Attachment #708513 - Attachment description: unregister enumerationTelephonyCallback. r=vicamo → patch for b2g18: unregister enumerationTelephonyCallback. r=vicamo
Hsin-Yi, will this patch be available in b2g-18_v1.0.0?
Blocks: 836891
https://hg.mozilla.org/mozilla-central/rev/987ebceef054
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → B2G C4 (2jan on)
No longer blocks: slim-fast
Does not make sense to create a regression issue.
Flags: in-moztrap-
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.