Closed Bug 994411 Opened 10 years ago Closed 10 years ago

[B2G][Bluetooth] Making outbound call with bluetooth headset paired causes phone to restart

Categories

(Firefox OS Graveyard :: Bluetooth, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:1.4+, firefox30 wontfix, firefox31 fixed, b2g-v1.3T unaffected, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S1 (9may)
blocking-b2g 1.4+
Tracking Status
firefox30 --- wontfix
firefox31 --- fixed
b2g-v1.3T --- unaffected
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: bzumwalt, Assigned: shawnjohnjr)

References

Details

(Keywords: regression)

Attachments

(4 files, 2 obsolete files)

Attached file Logcat
Description:
When user has a bluetooth headset paired to device and makes an outbound call, the phone restarts without warning before call connects. No crash report is generated. This issue only occurs on outgoing calls where a bluetooth headset is paired. Incoming calls with or without bluetooth headset as well as outgoing calls without headset result in expected behavior.

Repro Steps:
1) Updated Buri to BuildID: 20140409130909
2) Launch Settings app
3) Navigate to Bluetooth and enable bluetooth
4) Pair with bluetooth headset
5) Press home button then launch dialer
6) Dial a valid phone number and begin call

Actual:
Phone restarts before call can connect when making outgoing call with bluetooth headset paired.

Expected:
User can make outgoing calls with bluetooth headset paired.

Environmental Variables:
Device: Buri Master M-C Mozilla RIL
BuildID: 20140409130909
Gaia: 9d0b1bdf746823a94b13e6574c1d8304dc584763
Gecko: 5a5ed08df529
Version: 31.0a1
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 3/3, 100%
See attached: logcat
Issue does NOT occur on 1.4

Result: User can make outgoing calls with bluetooth headset paired.

Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140409000202
Gaia: 26983f356ecb1bcf30e862d334b5de790071803e
Gecko: e450e07e3a58
Version: 30.0a2
Firmware Version: v1.2-device.cfg
Is there a crash report message coming up? If so, can you include a crash report URL?
blocking-b2g: --- → 1.5?
Keywords: qawanted
See Comment 0: "No crash report is generated."
Keywords: qawanted
Issue DOES reproduce on 1.3T with Tarako device

Result: Phone restarts before call can connect when making outgoing call with bluetooth headset paired.

1.3T Environmental Variables:
Device: Tarako 1.3T
BuildID: 20140410004001
Gaia: 022b03a57e4b8c697a6066961e7581d07eb99305
Gecko: b9dba13d50a9
Version: 28.1
Firmware Version: sp6821a
Can you get an dmesg log here.

Moving 1.3T? per comment 4.
blocking-b2g: 2.0? → 1.3T?
Keywords: qawanted
I will try to reproduce it first on Tarako.
Assignee: nobody → shuang
triage: base on the bug symptom, 1.3T+
blocking-b2g: 1.3T? → 1.3T+
    Test on Tarako, this bug is reproducible. I attached gdb, but i cannot get backtrace for gecko.

    09-08 05:50:13.920 I/audio_pga(   88): 'VBC ADCR DG Switch' set to 0
    09-08 05:50:13.920 W/audio_hw_primary(   88): SetAudio_gain_by_devices out, devices:0x40001 
    09-08 05:50:13.920 W/audio_hw_primary(   88): SetCall_VolumePara successfully ,dac_pga_gain_l:0x7c ,dac_pga_gain_r:0x7c ,adc_pga_gain_l:0x30 ,adc_pga_gain_r:0x70 ,devices:0x40001 ,mode:2 
    09-08 05:50:13.920 W/audio_hw_primary(   88): looping now...
    09-08 05:50:13.920 W/audio_hw_primary(   88):  call start, Get CMD(5) from cp, paras_size:4 devices:0x1 mode:2
    09-08 05:50:13.920 W/audio_hw_primary(   88): SetParas_Switch_Incall, VBC Switch control to dsp...
    09-08 05:50:13.920 W/audio_hw_primary(   88): looping now...
    09-08 05:50:18.340 W/audio_hw_primary(   88):  call start, Get CMD(13) from cp, paras_size:0 devices:0x1 mode:2
    09-08 05:50:18.350 W/audio_hw_primary(   88): VBC_CMD_HAL_CLOSE, try lock
    09-08 05:50:18.350 W/audio_hw_primary(   88): VBC_CMD_HAL_CLOSE, got lock
    09-08 05:50:18.350 W/audio_hw_primary(   88): END CALL,close pcm device & switch to arm...
    09-08 05:50:18.360 W/audio_hw_primary(   88): looping now...
    09-08 05:50:22.540 I/GonkMemoryPressure(  660): Checking to see if memory pressure is over.
    09-08 05:50:22.550 I/GonkMemoryPressure(  660): Memory pressure is over.
    09-08 05:50:22.570 I/GonkMemoryPressure(  942): Checking to see if memory pressure is over.
    09-08 05:50:22.570 I/GonkMemoryPressure(  942): Memory pressure is over.
    09-08 05:50:27.810 I/GonkMemoryPressure(  660): Checking to see if memory pressure is over.
    09-08 05:50:27.840 I/GonkMemoryPressure(  660): Memory pressure is over.
    09-08 05:50:29.770 I/log     ( 1013): <4>0[ 582.506595] lowmem_shrink select 657 (sh), adj 0, size 47, to kill 
    09-08 05:50:29.780 I/ServiceManager(   77): service 'permission' died
    09-08 05:50:29.790 I/ServiceManager(   77): service 'media.resource_manager' died
gdb seems to catch SIGKILL.
Child terminated with signal = 0x9 (SIGKILL)

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
Opps! I'm not sure who sends SIGKILL to b2g now. But it looks like killing process sh (/system/bin/sh)?

root      898   878   756    300   c453739c 400cffcc S /system/bin/sh
root      900   898   436    144   c453739c 0002472c S gdbserver


In logcat,
09-08 06:45:55.210 I/log     ( 1211): <4>0[ 833.652316] lowmem_shrink select 898 (sh), adj 0, size 73, to kill 
09-08 06:45:59.270 I/GonkMemoryPressure(  903): Checking to see if memory pressure is over.
09-08 06:45:59.290 I/GonkMemoryPressure(  903): Memory pressure is over.
09-08 06:45:59.490 I/GonkMemoryPressure( 1121): Checking to see if memory pressure is over.
09-08 06:46:00.400 I/GonkMemoryPressure( 1121): Memory pressure is over.
09-08 06:46:02.420 I/ServiceManager(   77): service 'permission' died
09-08 06:46:02.420 I/ServiceManager(   77): service 'media.resource_manager' died
without gdb attached, it looks like b2g was been selected.

09-08 06:52:40.410 I/log     (  577): <4>0[ 186.318845] lowmem_shrink select 83 (b2g), adj 0, size 22964, to kill 
09-08 06:52:45.520 I/GonkMemoryPressure(   83): Checking to see if memory pressure is over.
09-08 06:52:45.520 I/GonkMemoryPressure(   83): Memory pressure is over.
09-08 06:52:49.770 I/log     (  580): <4>0[ 195.492637] lowmem_shrink select 83 (b2g), adj 0, size 28260, to kill 
09-08 06:52:49.800 I/ServiceManager(   77): service 'media.resource_manager' died
09-08 06:52:49.810 I/ServiceManager(   77): service 'permission' died
09-08 06:52:50.040 I/ServiceManager(   77): service 'media.audio_flinger' died
09-08 06:52:50.040 I/ServiceManager(   77): service 'media.player' died
Assignee: shuang → nobody
unassigned myself, seems it looks like not related bluetooth.
Component: Bluetooth → Performance
Whiteboard: 1.3tarakorun2
Priority: -- → P1
Whiteboard: 1.3tarakorun2 → [c=memory p= s= u=tarako] [MemShrink] 1.3tarakorun2
Can we get an about:memory report for this bug on trunk?
I can't get 'about memory' since the b2g process will be killed immediately after making outgoing call.
I will try to change KillUnderKB see if I can get 'about:memory'.
--- a/b2g/app/b2g.js
+++ b/b2g/app/b2g.js
-pref("hal.processPriorityManager.gonk.MASTER.KillUnderKB", 4096);
+pref("hal.processPriorityManager.gonk.MASTER.KillUnderKB", 2096);
shawnjohnjr@shawnjohnjr-BM6875-BM6675-BP6375:~/mytmp$ adb shell procrank
  PID      Vss      Rss      Pss      Uss  cmdline
 1245   55056K   52000K   39899K   33540K  /system/b2g/b2g
 1306   31992K   31224K   18047K   11216K  /system/b2g/plugin-container
 1349   20364K   20360K    9764K    5284K  /system/b2g/plugin-container
 1286   11836K   11832K    3919K     708K  /system/b2g/plugin-container
 1244     772K     772K     275K     192K  /system/bin/mediaserver
 1095     496K     496K     269K     208K  /system/bin/bluetoothd
 1235     600K     600K     245K     168K  /system/bin/rild_sp
 1324     452K     452K     233K     216K  /system/bin/wpa_supplicant
.....
RAM: 100868K total, 1908K free, 0K buffers, 31812K cached, 1548K shmem, 7260K slab

  NAME  PID PPID CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER    
            b2g 1245    1   62.9    0 32.5 38.6 50.5 152.7       0 root    
         (Nuwa) 1286 1245    2.6    0  0.7  3.8 11.5  77.8       0 root    
     Homescreen 1306 1286   12.0   18  9.7 16.3 29.2  90.9       8 app_1306
(Preallocated a 1349 1286    2.5   18  5.2  9.5 19.9  84.8       1 root    

  oom_adj min_free
        0  4096 KB
        1  5120 KB
        2  6144 KB
        6  7168 KB
        8  8192 KB
       10 20480 KB
Maybe this bug is related to bug 989572?
Shawn, if you want to dig into this a little further I've found it useful to add printf_stderr() calls from gecko that show the current RSS.  Unfortunately thats currently our best method for seeing transient memory spikes.  Maybe this could help show where memory is spiking in the bluetooth stack?

To do this in mozilla-central you can do this in your C++ code:

  #include "nsMemoryReporterManager.h"

  int64_t rss = nsMemoryReporterManager::ResidentFast();
  printf_stderr("Current RSS: %lld\n", rss);

You probably also need to add "/xpcom/base" to your LOCAL_INCLUDES in the moz.build.

If you need to test on an older branch then the process is similar, but just has some extra steps.  In that case you need to do something like this:

  #include "nsMemoryReporterManager.h"

  nsCOMPTr<nsMemoryReporterManager> mrm = nsMemoryReporterManager::GetOrCreate();
  
  int64_t rss;
  mrm->GetResidentFast(&rss);
  printf_stderr("Current RSS: %lld\n", rss);

If you are in chrome js you can probably also get the nsMemoryReporterManager service and use the same resident fast accessor.  I have not personally done that yet, though.

Hope that helps.
Shawn, looks like you are working on this, do you mind taking this bug? Thanks
Flags: needinfo?(shuang)
Joe, this bug originally was been reported on Buri master branch. I think it's better to discuss tarako bug on Bug 995860, and focus on master branch first. Because I don't think they share the same reason. Can we track on Bug 995860 for tarako?
Flags: needinfo?(shuang)
Flags: needinfo?(jcheng)
Keywords: qawanted
Tracking this for 1.5 given comment #20.
blocking-b2g: 1.3T+ → 2.0+
Component: Performance → Bluetooth
Flags: needinfo?(jcheng)
Whiteboard: [c=memory p= s= u=tarako] [MemShrink] 1.3tarakorun2
Assignee: nobody → shuang
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #20)
> Joe, this bug originally was been reported on Buri master branch. I think
> it's better to discuss tarako bug on Bug 995860, and focus on master branch
> first. Because I don't think they share the same reason. Can we track on Bug
> 995860 for tarako?

It's very strange that I found even on buri with master gecko, b2g process was been killed by LMK. I'm looking into it. Seeing that procrank b2g process memory usage increases dramatically after dialing out outgoing call.
           NAME  PID NICE  USS  PSS  RSS VSIZE OOM_ADJ USER    
            b2g 2327    0 74.0 78.0 89.2 215.9       0 root    
                2398    0  2.3  5.4 16.1  52.2       0 root
(In reply to Ben Kelly [:bkelly] from comment #18)
> If you are in chrome js you can probably also get the
> nsMemoryReporterManager service and use the same resident fast accessor.  I
> have not personally done that yet, though.
> 
> Hope that helps.
I actually cannot do 'about:memory' because as long as making an outgoing call, memory usage increases a lot and in 1~2 seconds, b2g process will be killed.
On Buri master branch
Before making outgoing call with BT HFP.
NAME PID NICE  USS  PSS  RSS VSIZE OOM_ADJ USER   
b2g 133    0 48.4 52.9 66.7 178.8       0 root
After making outgoing call with BT HFP.
(I hooked gdb and interrupt immediately after making outgoing call before b2g is been killed)
NAME  PID NICE  USS  PSS  RSS VSIZE OOM_ADJ USER    
b2g 2327    0 74.0 78.0 89.2 215.9       0 root
Maybe I can try on Nexus4 since it has bigger memory, and I might have chance to get about-memory report and use dmd.
Any idea?
Flags: needinfo?(tzimmermann)
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #25)
> (In reply to Ben Kelly [:bkelly] from comment #18)
> > If you are in chrome js you can probably also get the
> > nsMemoryReporterManager service and use the same resident fast accessor.  I
> > have not personally done that yet, though.
> > 
> > Hope that helps.
> I actually cannot do 'about:memory' because as long as making an outgoing
> call, memory usage increases a lot and in 1~2 seconds, b2g process will be
> killed.

You don't need to do an about:memory report to use the technique I was referencing in comment 18.  While it does use the same C++ class, its just grabbing the RSS value so you can printf_stderr() it.

So if there is somewhere in the bluetooth code you know you are hitting with this workload, try printing out the RSS and trace how it changes as you move through the call stack.  Its very manual and tedious, but its the best way I've found for tracking this sort of thing down.
Switching this to unaffected to indicate that the 2.0 fix is being tracked here. bug 995860 is tracking the 1.3T-specific fix.
Whiteboard: [MemShrink]
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #28)
> Any idea?

I was able to kind of reproduce it with a Unagi. I do the STR, and as soon as I call, the phone stops responding to input. After a while, the it reboots.

The phone gets stuck in an (almost) endless loop of memory allocation in BluetoothHfpManager::HandleCallStateChange, because aCallIndex is -1. Full stack trace is attached.

>>>>>

#0  memset () at bionic/libc/arch-arm/bionic/memset.S:81
#1  0x40030bd6 in huge_dalloc (ptr=<value optimized out>) at /home/mozilla/Projects/mozilla/src/mozilla-central/memory/mozjemalloc/jemalloc.c:5275
#2  0x40030da4 in idalloc (ptr=0x53000000) at /home/mozilla/Projects/mozilla/src/mozilla-central/memory/mozjemalloc/jemalloc.c:4604
#3  0x4003185a in huge_ralloc (ptr=0x53000000, size=132124672) at /home/mozilla/Projects/mozilla/src/mozilla-central/memory/mozjemalloc/jemalloc.c:5246
#4  iralloc (ptr=0x53000000, size=132124672) at /home/mozilla/Projects/mozilla/src/mozilla-central/memory/mozjemalloc/jemalloc.c:4797
#5  realloc (ptr=0x53000000, size=132124672) at /home/mozilla/Projects/mozilla/src/mozilla-central/memory/mozjemalloc/jemalloc.c:6456
#6  0x426fe8fa in moz_xrealloc (ptr=0x53000000, size=132124672) at /home/mozilla/Projects/mozilla/src/mozilla-central/memory/mozalloc/mozalloc.cpp:84
#7  0x40cf6f10 in nsTArrayInfallibleAllocator::Realloc (this=0x45e63948, capacity=6606029, elemSize=20)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/xpcom/build/../glue/nsTArray.h:208
#8  nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity (this=0x45e63948, capacity=6606029, elemSize=20)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/xpcom/build/../glue/nsTArray-inl.h:170
#9  0x4169c962 in AppendElements<mozilla::dom::bluetooth::Call> (this=0x45e63948, item=...) at ../../dist/include/nsTArray.h:1236
#10 nsTArray_Impl<mozilla::dom::bluetooth::Call, nsTArrayInfallibleAllocator>::AppendElement<mozilla::dom::bluetooth::Call> (this=0x45e63948, item=...)
    at ../../dist/include/nsTArray.h:1253
#11 0x416a009c in mozilla::dom::bluetooth::BluetoothHfpManager::HandleCallStateChanged (this=0x45e638f0, aCallIndex=4294967295, aCallState=<value optimized out>, 
    aError=<value optimized out>, aNumber=..., aIsOutgoing=true, aIsConference=false, aSend=true)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/dom/bluetooth/bluez/BluetoothHfpManager.cpp:1397
#12 0x41690408 in mozilla::dom::bluetooth::TelephonyListener::CallStateChanged (this=<value optimized out>, aServiceId=<value optimized out>, aCallIndex=4294967295, 
    aCallState=1, aNumber=..., aIsActive=true, aIsOutgoing=true, aIsEmergency=false, aIsConference=false, aIsSwitchable=true, aIsMergeable=true)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/dom/bluetooth/BluetoothRilListener.cpp:189
#13 0x40d538e6 in NS_InvokeByIndex (that=0x47b2b700, methodIndex=3, paramCount=<value optimized out>, params=<value optimized out>)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:164
#14 0x415aab30 in CallMethodHelper::Invoke (this=0xbedcec68) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:2405
#15 CallMethodHelper::Call (this=0xbedcec68) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1746
#16 0x415abdac in XPCWrappedNative::CallMethod (ccx=..., mode=<value optimized out>)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1713
#17 0x415b1ce6 in XPC_WN_CallMethod (cx=0x403c9240, argc=<value optimized out>, vp=<value optimized out>)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1285
#18 0x4251f014 in js::CallJSNative (cx=0x403c9240, native=0x415b1bcd <XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)>, args=...)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/jscntxtinlines.h:239
#19 0x425306cc in js::Invoke (cx=0x403c9240, args=..., construct=js::NO_CONSTRUCT) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:474
#20 0x42412e5a in js_fun_apply (cx=0x403c9240, argc=<value optimized out>, vp=0xffffff87) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/jsfun.cpp:1017
#21 0x4251f014 in js::CallJSNative (cx=0x403c9240, native=0x42412ba9 <js_fun_apply(JSContext*, unsigned int, JS::Value*)>, args=...)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/jscntxtinlines.h:239
#22 0x425306cc in js::Invoke (cx=0x403c9240, args=..., construct=js::NO_CONSTRUCT) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:474
#23 0x4252b38c in Interpret (cx=0x403c9240, state=<value optimized out>) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:2621
#24 0x42530176 in js::RunScript (cx=0x403c9240, state=...) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:421
#25 0x42530756 in js::Invoke (cx=0x403c9240, args=..., construct=js::NO_CONSTRUCT) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:493
#26 0x42531086 in js::Invoke (cx=0x403c9240, thisv=..., fval=..., argc=3, argv=0xbedd0820, rval=...)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:530
#27 0x423e06d2 in JS_CallFunctionValue (cx=0x403c9240, obj=<value optimized out>, fval=..., args=..., rval=...)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/jsapi.cpp:4966
---Type <return> to continue, or q <return> to quit---
#28 0x415a7b5c in nsXPCWrappedJSClass::CallMethod (this=0x479334f0, wrapper=<value optimized out>, methodIndex=<value optimized out>, info_=0x444a7954, 
    nativeParams=0xbedd0b58) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedJSClass.cpp:1273
#29 0x415a4368 in nsXPCWrappedJS::CallMethod (this=0x47973440, methodIndex=26, info=0x444a7954, params=0xbedd0b58)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedJS.cpp:517
#30 0x40d542b4 in PrepareAndDispatch (self=<value optimized out>, methodIndex=<value optimized out>, args=0xbedd0c1c)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcstubs_arm.cpp:93
#31 0x40d538fc in SharedStub () from /home/mozilla/Projects/mozilla/src/B2G-master-unagi/objdir-gecko-debug/dist/bin/libxul.so
#32 0x40d538e6 in NS_InvokeByIndex (that=0x480f1170, methodIndex=26, paramCount=<value optimized out>, params=<value optimized out>)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:164
#33 0x415aab30 in CallMethodHelper::Invoke (this=0xbedd0db8) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:2405
#34 CallMethodHelper::Call (this=0xbedd0db8) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1746
#35 0x415abdac in XPCWrappedNative::CallMethod (ccx=..., mode=<value optimized out>)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1713
#36 0x415b1ce6 in XPC_WN_CallMethod (cx=0x403c9240, argc=<value optimized out>, vp=<value optimized out>)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1285
#37 0x4251f014 in js::CallJSNative (cx=0x403c9240, native=0x415b1bcd <XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)>, args=...)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/jscntxtinlines.h:239
#38 0x425306cc in js::Invoke (cx=0x403c9240, args=..., construct=js::NO_CONSTRUCT) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:474
#39 0x4252b38c in Interpret (cx=0x403c9240, state=<value optimized out>) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:2621
#40 0x42530176 in js::RunScript (cx=0x403c9240, state=...) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:421
#41 0x42530756 in js::Invoke (cx=0x403c9240, args=..., construct=js::NO_CONSTRUCT) at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:493
#42 0x42531086 in js::Invoke (cx=0x403c9240, thisv=..., fval=..., argc=1, argv=0xbedd1fe0, rval=...)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/vm/Interpreter.cpp:530
#43 0x426b2666 in DoCallFallback (cx=0x403c9240, frame=<value optimized out>, stub=0x48e20530, argc=<value optimized out>, vp=0xbedd1fd0, res=...)
    at /home/mozilla/Projects/mozilla/src/mozilla-central/js/src/jit/BaselineIC.cpp:8124
#44 0x4393f560 in ?? ()
#45 0x4393f560 in ?? ()
Flags: needinfo?(tzimmermann)
Line numbers are out-of-date in that stack trace, btw.
Good catch! Thomas, thanks for the hint. We found this caused by Telephony behavior changed. Telephony might provide call index to UINT32_MAX when RIL did not get valid response from Modem. And both 1.3T and master branch applied this Telephony change.

See Bug 990467.
This patch shall also be committed into v1.3T. Since Telephony patches of Bug 990467 are in v1.3T, https://bugzilla.mozilla.org/show_bug.cgi?id=990467#c51.

Given the fact that revert Bluetoooth firmware can fix Bug 995860 (which is similar bug) makes wonder why tarako does not have invalid aCallIndex value.
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #36)
> Given the fact that revert Bluetoooth firmware can fix Bug 995860 (which is
> similar bug) makes wonder why tarako does not have invalid aCallIndex value.

Well if the firmware change made the modem give invalid responses more often it would cause this, right?
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #34)
> Good catch! Thomas, thanks for the hint. We found this caused by Telephony
> behavior changed. Telephony might provide call index to UINT32_MAX when RIL
> did not get valid response from Modem. And both 1.3T and master branch
> applied this Telephony change.
> 
> See Bug 990467.

If Bug 990467 changed the Telephony API behavior are there other consumers of this API that need to be audited to ensure that they do not have bugs when they receive a call index of -1?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) (Away 4/19-5/7) from comment #37)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #36)
> > Given the fact that revert Bluetoooth firmware can fix Bug 995860 (which is
> > similar bug) makes wonder why tarako does not have invalid aCallIndex value.
> 
> Well if the firmware change made the modem give invalid responses more often
> it would cause this, right?
But it's just bluetooth firmware update instead of baseband modem part. Anyway, I will ask sprd for further detail.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) (Away 4/19-5/7) from comment #38)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #34)
> > Good catch! Thomas, thanks for the hint. We found this caused by Telephony
> > behavior changed. Telephony might provide call index to UINT32_MAX when RIL
> > did not get valid response from Modem. And both 1.3T and master branch
> > applied this Telephony change.
> > 
> > See Bug 990467.
> 
> If Bug 990467 changed the Telephony API behavior are there other consumers
> of this API that need to be audited to ensure that they do not have bugs
> when they receive a call index of -1?

Oh. Not -1 but UINT32_MAX
Well in an unsigned integer they're the same thing ;-)

That doesn't change my point though.  Do the other consumers of this API handle this properly?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) (Away 4/19-5/7) from comment #41)
> Well in an unsigned integer they're the same thing ;-)
My bad.
> That doesn't change my point though.  Do the other consumers of this API
> handle this properly?
I think only Bluetooth module listens CallStateChanged. Maybe Hsin-Yi can comment this.
Flags: needinfo?(htsai)
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #42)
> (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) (Away 4/19-5/7) from
> comment #41)
> > Well in an unsigned integer they're the same thing ;-)
> My bad.
> > That doesn't change my point though.  Do the other consumers of this API
> > handle this properly?
> I think only Bluetooth module listens CallStateChanged. Maybe Hsin-Yi can
> comment this.

Yes, in addition to TelephonyAPI, Bluetooth is the only consumer of nsITelephonyListenr.
Flags: needinfo?(htsai)
Comment on attachment 8407419 [details] [diff] [review]
Bug 994411 - [bluez] Ignore pending MO call index,  while  making MO call with bluetooth headset

Review of attachment 8407419 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. Thanks to both Shawn and Thomas.
Attachment #8407419 - Flags: review?(echou) → review+
Just realized that we still need another fix for Bluedroid implementation on Gecko master. Shawn, mind taking this?
Flags: needinfo?(shuang)
Attached patch Bug994411-bluedroid.patch (obsolete) — Splinter Review
Flags: needinfo?(shuang)
Comment on attachment 8408067 [details] [diff] [review]
Bug 994411 - [bluedroid] Ignore pending MO call index, while making MO call with bluetooth headset, r=echou

Review of attachment 8408067 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks. :)
Attachment #8408067 - Flags: review?(echou) → review+
Attachment #8408067 - Attachment description: Bug 994411 - [bluedroid] Ignore pending MO call index, while making MO call with bluetooth headset → Bug 994411 - [bluedroid] Ignore pending MO call index, while making MO call with bluetooth headset, r=echou
https://hg.mozilla.org/mozilla-central/rev/efe497928e78
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S1 (9may)
blocking-b2g: 2.0+ → 1.4?
Flags: needinfo?(shuang)
We're not taking the uplift here. Please backout the regressing patch that caused bug 1021088. It's too late to invoke code churn with high risk patches on 1.4 at this point.
blocking-b2g: 1.4? → 2.0+
Hi Jason, If this bug have to be in 1.4, we have to land this. because it is requested from partner, we need to know Ivan's opinion.

Hi Ivan, you asked to land Bug 993255 and bug 990467. Does it must have in 1.4?
blocking-b2g: 2.0+ → 1.4?
Flags: needinfo?(itsay)
We need this in v1.4 as well.
Please see my comment in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1021088#c7
Flags: needinfo?(itsay)
Attachment #8435686 - Attachment description: Bug 994411 - [bluez] Ignore pending MO call index, while making MO call with bluetooth headset, r=echou, a=1.4+ → Bug 994411 - Ignore pending MO call index, while making MO call with bluetooth headset, r=echou, a=1.4+ (v.1.4)
I'm not sure we're going to backout patches in bug 990467. But I updated bug 994411 patch for v1.4. Feel free to uplift once granted. Thanks.
(In reply to Ken Chang[:ken] from comment #56)
> Hi Jason, If this bug have to be in 1.4, we have to land this. because it is
> requested from partner, we need to know Ivan's opinion.
> 
> Hi Ivan, you asked to land Bug 993255 and bug 990467. Does it must have in
> 1.4?

I don't think that's a compelling argument for an uplift. If the partner wants it & it's risky, then they should take their own branch, not in 1.4 generally. This is far too dangerous to take into 1.4 at this point.
blocking-b2g: 1.4? → 2.0+
Ken provided a good analysis in comment 15 in bug 1021088, and I think we can take it into consideration and to uplift this bug to 1.4.
blocking-b2g: 2.0+ → 1.4?
Blocks: 1021088
Depends on: 990467
blocking-b2g: 1.4? → 1.4+
Whiteboard: [status: uplift needed]
You need to log in before you can comment on or make changes to this bug.