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)
Tracking
(blocking-b2g:1.4+, firefox30 wontfix, firefox31 fixed, b2g-v1.3T unaffected, b2g-v1.4 fixed, b2g-v2.0 fixed)
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)
427.46 KB,
text/plain
|
Details | |
1.14 KB,
patch
|
Details | Diff | Splinter Review | |
1.17 KB,
patch
|
echou
:
review+
|
Details | Diff | Splinter Review |
2.34 KB,
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•10 years ago
|
||
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
Comment 2•10 years ago
|
||
Is there a crash report message coming up? If so, can you include a crash report URL?
blocking-b2g: --- → 1.5?
Keywords: qawanted
Reporter | ||
Comment 4•10 years ago
|
||
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
Assignee | ||
Comment 6•10 years ago
|
||
I will try to reproduce it first on Tarako.
Assignee: nobody → shuang
Assignee | ||
Comment 8•10 years ago
|
||
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
Assignee | ||
Comment 9•10 years ago
|
||
gdb seems to catch SIGKILL. Child terminated with signal = 0x9 (SIGKILL) Program terminated with signal SIGKILL, Killed. The program no longer exists.
Assignee | ||
Comment 10•10 years ago
|
||
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
Assignee | ||
Comment 11•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Assignee: shuang → nobody
Assignee | ||
Comment 12•10 years ago
|
||
unassigned myself, seems it looks like not related bluetooth.
Assignee | ||
Updated•10 years ago
|
Component: Bluetooth → Performance
Updated•10 years ago
|
Whiteboard: 1.3tarakorun2
Updated•10 years ago
|
Priority: -- → P1
Whiteboard: 1.3tarakorun2 → [c=memory p= s= u=tarako] [MemShrink] 1.3tarakorun2
Comment 13•10 years ago
|
||
Can we get an about:memory report for this bug on trunk?
Assignee | ||
Comment 14•10 years ago
|
||
I can't get 'about memory' since the b2g process will be killed immediately after making outgoing call.
Assignee | ||
Comment 15•10 years ago
|
||
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);
Assignee | ||
Comment 16•10 years ago
|
||
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
Assignee | ||
Comment 17•10 years ago
|
||
Maybe this bug is related to bug 989572?
Comment 18•10 years ago
|
||
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.
Comment 19•10 years ago
|
||
Shawn, looks like you are working on this, do you mind taking this bug? Thanks
Flags: needinfo?(shuang)
Assignee | ||
Comment 20•10 years ago
|
||
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)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(jcheng)
Updated•10 years ago
|
Component: Performance → Bluetooth
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(jcheng)
Whiteboard: [c=memory p= s= u=tarako] [MemShrink] 1.3tarakorun2
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → shuang
Assignee | ||
Comment 23•10 years ago
|
||
(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.
Assignee | ||
Comment 24•10 years ago
|
||
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
Assignee | ||
Comment 25•10 years ago
|
||
(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.
Assignee | ||
Comment 26•10 years ago
|
||
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
Assignee | ||
Comment 27•10 years ago
|
||
Maybe I can try on Nexus4 since it has bigger memory, and I might have chance to get about-memory report and use dmd.
Comment 29•10 years ago
|
||
(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.
Comment 30•10 years ago
|
||
Switching this to unaffected to indicate that the 2.0 fix is being tracked here. bug 995860 is tracking the 1.3T-specific fix.
Updated•10 years ago
|
Whiteboard: [MemShrink]
Comment 32•10 years ago
|
||
(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)
Comment 33•10 years ago
|
||
Line numbers are out-of-date in that stack trace, btw.
Assignee | ||
Comment 34•10 years ago
|
||
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.
Assignee | ||
Comment 35•10 years ago
|
||
Attachment #8407419 -
Flags: review?(echou)
Assignee | ||
Comment 36•10 years ago
|
||
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?
Whiteboard: [MemShrink]
Assignee | ||
Comment 39•10 years ago
|
||
(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.
Assignee | ||
Comment 40•10 years ago
|
||
(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?
Assignee | ||
Comment 42•10 years ago
|
||
(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)
Comment 43•10 years ago
|
||
(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 44•10 years ago
|
||
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+
Assignee | ||
Updated•10 years ago
|
Attachment #8407419 -
Attachment is obsolete: true
Assignee | ||
Comment 45•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 46•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/efe497928e78
Keywords: checkin-needed
Comment 47•10 years ago
|
||
Just realized that we still need another fix for Bluedroid implementation on Gecko master. Shawn, mind taking this?
Flags: needinfo?(shuang)
Assignee | ||
Comment 48•10 years ago
|
||
Flags: needinfo?(shuang)
Assignee | ||
Updated•10 years ago
|
Attachment #8408063 -
Attachment is obsolete: true
Assignee | ||
Comment 49•10 years ago
|
||
Attachment #8408067 -
Flags: review?(echou)
Comment 50•10 years ago
|
||
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+
Assignee | ||
Updated•10 years ago
|
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
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 51•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/bc0034c4496c
Keywords: checkin-needed
Comment 52•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/efe497928e78
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Target Milestone: --- → 2.0 S1 (9may)
Assignee | ||
Comment 54•10 years ago
|
||
Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1021088#c4, now v1.4 also required to be updated.
Assignee | ||
Updated•10 years ago
|
blocking-b2g: 2.0+ → 1.4?
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(shuang)
Comment 55•10 years ago
|
||
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+
Comment 56•10 years ago
|
||
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)
Comment 57•10 years ago
|
||
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)
Assignee | ||
Comment 58•10 years ago
|
||
Flags: needinfo?(shuang)
Assignee | ||
Updated•10 years ago
|
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)
Assignee | ||
Comment 59•10 years ago
|
||
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.
Comment 60•10 years ago
|
||
(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+
Comment 61•10 years ago
|
||
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?
Updated•10 years ago
|
blocking-b2g: 1.4? → 1.4+
Assignee | ||
Updated•10 years ago
|
Whiteboard: [status: uplift needed]
Comment 62•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/0ed9bc2696aa
You need to log in
before you can comment on or make changes to this bug.
Description
•