Closed Bug 858436 Opened 12 years ago Closed 12 years ago

[Settings][Bluetooth] Device reboot when try to connect headset multiple times

Categories

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

Product:
Firefox OS Graveyard
Component:
Bluetooth
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
1.1 QE1 (5may)

People

(Reporter: leo.bugzilla.gecko, Assigned: shawnjohnjr)

Details

(Whiteboard: [TD-9255])

Attachments

(3 files, 2 obsolete files)

Reproduce movie for this bug
835.57 KB, application/octet-stream
Details
minidump_stackwalk tool
1.30 MB, application/zip
Details
dump&hcidump for reset
48.75 KB, application/x-zip-compressed
Details
Dear Mozilla Team, Step: 1. BT headset connect 2. BT headset off 3. Paired devices list -> BT headset select -> Connect click -> Ok click 4. BT headset on -> paired devices list -> BT headset select -> Connect click Expected Result: Connect BT Headset. Result: Phone Reset. Comparison Result: - Model Comparing : ZTE same please check the issue.
Component: Gaia::Bluetooth File Transfer → Gaia::Settings
Hardware: x86_64 → ARM
Dear Mozilla, I uploaded the reproduce movie for your understand. Please check this. Thanks.
I see your attached video. The device crash when try to pair headset again. Gina, Have you ever seen the issue before? Thanks.
Thanks, Ian. We'll take a look on this.
Summary: [Bluetooth]BT connect error → [Settings][Bluetooth] Device reboot when try to pair headset again
Summary: [Settings][Bluetooth] Device reboot when try to pair headset again → [Settings][Bluetooth] Device reboot when try to connect headset multiple times
I've checked the video and I think that it is caused by sending multiple connect request in a short time. However, I'd like to get more details and need your help to get hcidump. Here are some information for getting hcidump: https://wiki.mozilla.org/B2G/Bluetooth#Helpful_Debugging_Information Please attach the full hcidump, Thanks.
Flags: needinfo?(leo.bugzilla.gecko)
backtrace of gdb may also help, thanks.
blocking-b2g: --- → leo?
I'm not sure if testers can run gdb for getting backtrace while testing. In order to getting crash reports, you can also try to get crash report. Here is "how-to". How to enable breakpad/crashreporter to have minidump 1) apply following patch in gecko to enable dmp/extra file dump diff --git a/toolkit/xre/nsAppRunner.cpp b/toolkit/xre/nsAppRunner.cpp index e3dd0df..5ebe417 100644 --- a/toolkit/xre/nsAppRunner.cpp +++ b/toolkit/xre/nsAppRunner.cpp @@ -2972,6 +2972,7 @@ XREMain::XRE_mainInit(const nsXREAppData* aAppData, bool* aExitFlag) return 1; #ifdef MOZ_CRASHREPORTER + SaveToEnv("MOZ_CRASHREPORTER=1"); if (EnvHasValue("MOZ_CRASHREPORTER")) { mAppData->flags |= NS_XRE_ENABLE_CRASH_REPORTER; } 2) ./build.sh gecko && ./flash.sh gecko 3) . setup.sh && make buildsymbols dmp and extra file will save under phone store /data/b2g/mozilla/Crash Report/pending/ when segmentation fault. File name looks like 02a350f7-248a-c6bb-3f607943-4f905109.dmp 02a350f7-248a-c6bb-3f607943-4f905109.extra 4) adb pull /data/b2g/mozilla/Crash\ Report/pending/<dmgfilename> ./ 5) ./minidump_stackwalk dmpfilename objdir-gecko/dist/crashreporter-symbols/ > dmp_result.txt Note: 1. objdir-gecko folder is where gecko symbol that the build you currently used. 2. minidump_stackwalk is a tool will parse and output where b2g crashes
Crash report parse tool. Since we don't have exactly the same symbol file to resolve crash point. Please use it to report.
Triage 4/10 - Leo+ as phone resets.
blocking-b2g: leo? → leo+
Attached file dump&hcidump for reset —
Dear Mozilla Team, I did not convert to txt from dmp. error message on running minidump as below. ./minidump_stackwalk: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./minidump_stackwalk) So, I upload the dmp and extra file and hcidump during the same time period. Please check this. This bug is easily reproducible regardless of headset. Thanks.
Flags: needinfo?(leo.bugzilla.gecko)
Assignee: nobody → gyeh
error message caused by different glibc version. You can build from your machine. 1. svn checkout http://google-breakpad.googlecode.com/svn/trunk/ google-breakpad-read-only 2. cd google-breakpad-read-only 3. ./configure 4. make
I can reproduce this issue. I will help this. Thanks for reporting.
It looks like NS_RUNTIMEABORT("unknown union type") from ipc. [Parent 774] ###!!! ABORT: unknown union type: file objdir-gecko-v101/ipc/ipdl/PBluetoothRequestParent.cpp, line 449 I have also confirmed that what the reporter provided dmp file with the same crash signature.
Whiteboard: [TD-9255]
Target Milestone: --- → Leo QE1 (5may)
Component: Gaia::Settings → Bluetooth
(gdb) bt #0 mozilla::dom::bluetooth::PBluetoothRequestParent::Write (this=0x480ff4a0, __v=..., __msg=0x480c71c0) at /home/shawnjohnjr/workspace1/B2G/objdir-gecko-b2g18/ipc/ipdl/PBluetoothRequestParent.cpp:449 #1 0x412a3994 in mozilla::dom::bluetooth::PBluetoothRequestParent::Send__delete__ (actor=0x480ff4a0, response=...) at /home/shawnjohnjr/workspace1/B2G/objdir-gecko-b2g18/ipc/ipdl/PBluetoothRequestParent.cpp:79 #2 0x41006238 in mozilla::dom::bluetooth::BluetoothRequestParent::ReplyRunnable::Run (this=0x480ff780) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/ipc/BluetoothParent.cpp:50 #3 0x4139a522 in nsThread::ProcessNextEvent (this=0x40409940, mayWait=<value optimized out>, result=0xbed027ff) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/xpcom/threads/nsThread.cpp:620 #4 0x4137a94e in NS_ProcessNextEvent_P (thread=0x480ff4a0, mayWait=false) at /home/shawnjohnjr/workspace1/B2G/objdir-gecko-b2g18/xpcom/build/nsThreadUtils.cpp:237 #5 0x41293c68 in mozilla::ipc::MessagePump::Run (this=0x40402460, aDelegate=0x404310c0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/ipc/glue/MessagePump.cpp:82 #6 0x413bc3d8 in MessageLoop::RunInternal (this=0x1000000) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:216 #7 0x413bc48e in MessageLoop::RunHandler (this=0x404310c0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:209 #8 MessageLoop::Run (this=0x404310c0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:183 #9 0x41219f64 in nsBaseAppShell::Run (this=0x404cd8e0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/widget/xpwidgets/nsBaseAppShell.cpp:163 #10 0x4117d7cc in nsAppStartup::Run (this=0x42e798e0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/toolkit/components/startup/nsAppStartup.cpp:290 #11 0x40badd7a in XREMain::XRE_mainRun (this=0xbed029bc) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3794 #12 0x40bb03e4 in XREMain::XRE_main (this=0xbed029bc, argc=<value optimized out>, argv=0xbed04ba4, aAppData=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3860 #13 0x40bb0530 in XRE_main (argc=1, argv=0xbed04ba4, aAppData=0x1f170, aFlags=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3935 #14 0x0000999e in do_main (argc=1, argv=0xbed04ba4) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/b2g/app/nsBrowserApp.cpp:168 #15 main (argc=1, argv=0xbed04ba4) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/b2g/app/nsBrowserApp.cpp:261 (gdb) l 444 Write((__v).get_BluetoothReplyError(), __msg); 445 return; 446 } 447 default: 448 { 449 NS_RUNTIMEABORT("unknown union type"); 450 return; 451 } 452 } 453 }
It looks like BluetoothReply of type is BluetoothReply::T__None, which cause assertion. (const mozilla::dom::bluetooth::BluetoothReply &) @0x480c71c0: {mValue = {VBluetoothReplySuccess = " \t\301A@0\tI \000\000\000@\000\000", VBluetoothReplyError = " \t\301A@0\tI \000\000"}, mType = mozilla::dom::bluetooth::BluetoothReply::T__None}
Update easier way to reproduce this crash: 1. Try to connect one device already in the paired device, but out of range 2. When it's in connecting state, just fast continuously tap device in the Setting paired device
About the crash, I had investigated bug 830038, and the crash report of that bug is similar as this. Although frame 0 seems not the same, it should still be worth making a quick note here.
Hi Eric, bug 830038 you referred to. I think the following pattern is much more similar. Anyway, I believe this is not the same bug i previous identified. (gdb) bt #0 jemalloc_crash () at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/memory/mozjemalloc/jemalloc.c:1582 #1 0x40068a38 in arena_run_reg_dalloc (ptr=<value optimized out>, offset=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/memory/mozjemalloc/jemalloc.c:3336 #2 arena_dalloc_small (ptr=<value optimized out>, offset=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/memory/mozjemalloc/jemalloc.c:4540 #3 arena_dalloc (ptr=<value optimized out>, offset=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/memory/mozjemalloc/jemalloc.c:4668 #4 0x40069944 in free (ptr=0x0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/memory/mozjemalloc/jemalloc.c:6589 #5 0x4181602a in moz_free (ptr=0x0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/memory/mozalloc/mozalloc.cpp:48 #6 0x410055d4 in operator delete (this=0x48737520, __in_chrg=<value optimized out>) at ../../dist/include/mozilla/mozalloc.h:224 #7 ~nsAutoPtr (this=0x48737520, __in_chrg=<value optimized out>) at ../../dist/include/nsAutoPtr.h:71 #8 ~BluetoothReplyRunnable (this=0x48737520, __in_chrg=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/BluetoothReplyRunnable.cpp:31 #9 0x410055e4 in ~BluetoothReplyRunnable (this=0x0, __in_chrg=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/BluetoothReplyRunnable.cpp:31 #10 0x40bbeb96 in nsTransportEventSinkProxy::Release (this=0x48737520) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/netwerk/base/src/nsTransportUtils.cpp:92 #11 0x40baca32 in ~nsCOMPtr_base (this=0x489719a8, __in_chrg=<value optimized out>) at ../../../dist/include/nsCOMPtr.h:408 #12 0x4100b9e2 in ~GetDeviceChannelForConnectRunnable (this=0x489719a0, __in_chrg=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/linux/BluetoothDBusService.cpp:2632 #13 0x4100b9f4 in ~GetDeviceChannelForConnectRunnable (this=0x0, __in_chrg=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/linux/BluetoothDBusService.cpp:2632 #14 0x40bbeb96 in nsTransportEventSinkProxy::Release (this=0x489719a0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/netwerk/base/src/nsTransportUtils.cpp:92 #15 0x40baca32 in ~nsCOMPtr_base (this=0x47effe80, __in_chrg=<value optimized out>) at ../../../dist/include/nsCOMPtr.h:408 #16 0x4139a542 in ~nsCOMPtr (this=0x47397520, mayWait=<value optimized out>, result=0x47effeaf) at ../../dist/include/nsCOMPtr.h:451 #17 nsThread::ProcessNextEvent (this=0x47397520, mayWait=<value optimized out>, result=0x47effeaf) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/xpcom/threads/nsThread.cpp:625 #18 0x4137a956 in NS_ProcessNextEvent_P (thread=0x0, mayWait=true) at /home/shawnjohnjr/workspace1/B2G/objdir-gecko-b2g18/xpcom/build/nsThreadUtils.cpp:237 #19 0x4139a978 in nsThread::ThreadFunc (arg=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/xpcom/threads/nsThread.cpp:258 #20 0x4036eacc in _pt_root (arg=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/nsprpub/pr/src/pthreads/ptthread.c:191 #21 0x4008fe18 in __thread_entry (func=0x4036ea41 <_pt_root>, arg=0x4730c780, tls=<value optimized out>) at bionic/libc/bionic/pthread.c:217 #22 0x4008f96c in pthread_create (thread_out=<value optimized out>, attr=0xbee144d4, start_routine=0x4036ea41 <_pt_root>, arg=0x4730c780) at bionic/libc/bionic/pthread.c:357 #23 0x00000000 in ?? ()
Priority: -- → P2
If enabling debug mode, I hit crash always in Write function. I think it could be different problem as Comment 13. void PBluetoothRequestParent::Write(... else { id = (__v)->mId; (gdb) bt #0 mozilla::dom::bluetooth::PBluetoothRequestParent::Write (this=0x5a5a5a5a, __v=0x5a5a5a5a, __msg=0x49b0d700, __nullable=false) at /home/shawnjohnjr/workspace1/B2G/objdir-gecko-b2g18/ipc/ipdl/PBluetoothRequestParent.cpp:629 #1 0x4182458e in mozilla::dom::bluetooth::PBluetoothRequestParent::Send__delete__ (actor=0x5a5a5a5a, response=...) at /home/shawnjohnjr/workspace1/B2G/objdir-gecko-b2g18/ipc/ipdl/PBluetoothRequestParent.cpp:78 #2 0x413bbb2e in mozilla::dom::bluetooth::BluetoothRequestParent::ReplyRunnable::Run (this=0x49e45460) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/ipc/BluetoothParent.cpp:50 #3 0x419ca8ee in nsThread::ProcessNextEvent (this=0x40304320, mayWait=<value optimized out>, result=0xbec7070f) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/xpcom/threads/nsThread.cpp:620 #4 0x41992118 in NS_ProcessNextEvent_P (thread=0x5a5a5a5a, mayWait=false) at /home/shawnjohnjr/workspace1/B2G/objdir-gecko-b2g18/xpcom/build/nsThreadUtils.cpp:237 #5 0x4180acf2 in mozilla::ipc::MessagePump::Run (this=0x40302490, aDelegate=0x403310c0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/ipc/glue/MessagePump.cpp:82 #6 0x41a0070a in MessageLoop::RunInternal (this=0x403310c0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:216 #7 0x41a0076a in MessageLoop::RunHandler (this=0x403310c0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:209 #8 MessageLoop::Run (this=0x403310c0) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:183 #9 0x41743dfe in nsBaseAppShell::Run (this=0x403fd880) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/widget/xpwidgets/nsBaseAppShell.cpp:163 #10 0x4163ca0a in nsAppStartup::Run (this=0x4381a190) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/toolkit/components/startup/nsAppStartup.cpp:290 #11 0x40c451e6 in XREMain::XRE_mainRun (this=0xbec709a4) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3794 #12 0x40c478cc in XREMain::XRE_main (this=0xbec709a4, argc=<value optimized out>, argv=0xbec72ba4, aAppData=0x21170) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3860 #13 0x40c47a7a in XRE_main (argc=1, argv=0xbec72ba4, aAppData=0x21170, aFlags=<value optimized out>) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3935 #14 0x00009b12 in do_main (argc=1, argv=0xbec72ba4) at /home/shawnjohnjr/workspace1/B2G-2/B2G/gecko/b2g/app/nsBrowserApp.cpp:168
It is interesting that using the latest version b2g version around April 13, I can hit assertion easily. But today I synced up the latest code problem does not appear at all. Although Bluetooth does not change any IPC code. Can reporter also try the latest gecko? Meanwhile, I will also try to find out why problem disappeared.
Flags: needinfo?(leo.bugzilla.gecko)
It looks like before calling Send__delete__ function, mType is not T__None, but BluetoothReplyError, but somehow inside mRequest->Send__delete__(), value changed. at /home/workspace1/B2G-2/B2G/gecko/dom/bluetooth/ipc/BluetoothParent.cpp:51 51 if (!mRequest->Send__delete__(mRequest, *mReply)) { (gdb) p *mReply.mRawPtr $16 = {mValue = {VBluetoothReplySuccess = " \031\301A\000\062\216G \000\000\000@\000\000", VBluetoothReplyError = " \031\301A\000\062\216G \000\000"}, mType = mozilla::dom::bluetooth::BluetoothReply::T__None}
(In reply to Shawn Huang from comment #19) > It is interesting that using the latest version b2g version around April 13, > I can hit assertion easily. But today I synced up the latest code problem > does not appear at all. around commit db16b691fbdd26b9c08ea2a7ba8b1025a7cbf037, i can easily reproduce this bug. Use the latest version, problem cannot be reproduced.
Dear Mozilla Team, I have tested the latest version, but this bug is not repoduced. Our gaia & gecko version is below. - Build ID : 20130421070203 - Gaia : 5cbb19e4bb78a7ad879fbe4b9a841e1c35714f5c - Gecko : 950b402b6188bb2f3ce3176e620ed5249719d720 It seems nothing has changed bluetooth code. Why this bug is not occurred?
Flags: needinfo?(leo.bugzilla.gecko)
Assignee: gyeh → shuang
We found the problem is because probably freed if there is any continuous connection request. In BluetoothHfpManager::connect(), BluetoothReplyRunnable mRunnable will be assigned many times. It is possible that BluetoothReplyRunnable be freed already and when OnConnectError returned. We need to review this part of code anyway. Comment 17, comment 18 could be similar problem and results from BluetoothRelyRunnable.
Attached patch Bug 858436 (obsolete) — — Splinter Review
It is supposed to consider multiple connection request condition. Can we add some protection here?
Attachment #743014 - Flags: feedback?(gyeh)
Attachment #743014 - Flags: feedback?(echou)
Regarding Comment 17, here is the place we crashed. Breakpoint 5, ~BluetoothReplyRunnable (this=0x426a778f, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/BluetoothReplyRunnable.cpp:31 31 BluetoothReplyRunnable::~BluetoothReplyRunnable() #0 ~BluetoothReplyRunnable (this=0x426a778f, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/BluetoothReplyRunnable.cpp:31 #1 0x415af230 in ~ReplyRunnable (this=0x489b1c60, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/ipc/BluetoothParent.cpp:29 #2 0x415af262 in ~ReplyRunnable (this=0x489b1c60, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/ipc/BluetoothParent.cpp:29 #3 0x40c579f6 in nsTransportEventSinkProxy::Release (this=0x489b1c60) at /home/sr/workspace1/B2G-2/B2G/gecko/netwerk/base/src/nsTransportUtils.cpp:92 #4 0x40c2b070 in ~nsCOMPtr_base (this=0x442933c8, __in_chrg=<value optimized out>) at ../../dist/include/nsCOMPtr.h:408 #5 0x415c08ac in ~ConnectBluetoothSocketRunnable (this=0x442933c0, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/linux/BluetoothDBusService.cpp:2581 #6 0x415c08e6 in ~ConnectBluetoothSocketRunnable (this=0x442933c0, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/linux/BluetoothDBusService.cpp:2581 #7 0x40c579f6 in nsTransportEventSinkProxy::Release (this=0x442933c0) at /home/sr/workspace1/B2G-2/B2G/gecko/netwerk/base/src/nsTransportUtils.cpp:92 #8 0x40c2b070 in ~nsCOMPtr_base (this=0xbec106bc, __in_chrg=<value optimized out>) at ../../dist/include/nsCOMPtr.h:408 #9 0x40c2b10c in ~nsCOMPtr (this=0xbec106bc, __in_chrg=<value optimized out>) at ../../dist/include/nsCOMPtr.h:835 #10 0x41da58b0 in nsThread::ProcessNextEvent (this=0x40409940, mayWait=false, result=0xbec1071f) at /home/sr/workspace1/B2G-2/B2G/gecko/xpcom/threads/nsThread.cpp:625 #11 0x41d5f5aa in NS_ProcessNextEvent_P (thread=0x40409940, mayWait=false) at /home/sr/workspace1/B2G/objdir-gecko-b2g18-nondbg/xpcom/build/nsThreadUtils.cpp:237 #12 0x41b30a68 in mozilla::ipc::MessagePump::Run (this=0x40402460, aDelegate=0x404310c0) at /home/sr/workspace1/B2G-2/B2G/gecko/ipc/glue/MessagePump.cpp:82 #13 0x41dec1fc in MessageLoop::RunInternal (this=0x404310c0) at /home/sr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:216 #14 0x41dec1ce in MessageLoop::RunHandler (this=0x404310c0) at /home/sr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:209 #15 0x41dec176 in MessageLoop::Run (this=0x404310c0) at /home/sr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:183 #16 0x41a2a79e in nsBaseAppShell::Run (this=0x404b68e0) at /home/sr/workspace1/B2G-2/B2G/gecko/widget/xpwidgets/nsBaseAppShell.cpp:163 #17 0x418dc9c4 in nsAppStartup::Run (this=0x44271b20) at /home/sr/workspace1/B2G-2/B2G/gecko/toolkit/components/startup/nsAppStartup.cpp:290 #18 0x40c3423c in XREMain::XRE_mainRun (this=0xbec10990) at /home/sr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3794 #19 0x40c34470 in XREMain::XRE_main (this=0xbec10990, argc=1, argv=0xbec12ba4, aAppData=0x36180) at /home/sr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3860 #20 0x40c34606 in XRE_main (argc=1, argv=0xbec12ba4, aAppData=0x36180, aFlags=0) at /home/sr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3935 #21 0x00009d5c in do_main (argc=1, argv=0xbec12ba4) at /home/sr/workspace1/B2G-2/B2G/gecko/b2g/app/nsBrowserApp.cpp:168 #22 0x0000a02a in main (argc=1, argv=0xbec12ba4) at /home/sr/workspace1/B2G-2/B2G/gecko/b2g/app/nsBrowserApp.cpp:261 Breakpoint 5, ~BluetoothReplyRunnable (this=0x442c3460, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/BluetoothReplyRunnable.cpp:31 31 BluetoothReplyRunnable::~BluetoothReplyRunnable() #0 ~BluetoothReplyRunnable (this=0x442c3460, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/BluetoothReplyRunnable.cpp:31 #1 0x415af230 in ~ReplyRunnable (this=0x489f35a0, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/ipc/BluetoothParent.cpp:29 #2 0x415af262 in ~ReplyRunnable (this=0x489f35a0, __in_chrg=<value optimized out>) at /home/sr/workspace1/B2G-2/B2G/gecko/dom/bluetooth/ipc/BluetoothParent.cpp:29 #3 0x40c579f6 in nsTransportEventSinkProxy::Release (this=0x489f35a0) at /home/sr/workspace1/B2G-2/B2G/gecko/netwerk/base/src/nsTransportUtils.cpp:92 #4 0x40c2b070 in ~nsCOMPtr_base (this=0xbec106bc, __in_chrg=<value optimized out>) at ../../dist/include/nsCOMPtr.h:408 #5 0x40c2b10c in ~nsCOMPtr (this=0xbec106bc, __in_chrg=<value optimized out>) at ../../dist/include/nsCOMPtr.h:835 #6 0x41da58b0 in nsThread::ProcessNextEvent (this=0x40409940, mayWait=false, result=0xbec1071f) at /home/sr/workspace1/B2G-2/B2G/gecko/xpcom/threads/nsThread.cpp:625 #7 0x41d5f5aa in NS_ProcessNextEvent_P (thread=0x40409940, mayWait=false) at /home/sr/workspace1/B2G/objdir-gecko-b2g18-nondbg/xpcom/build/nsThreadUtils.cpp:237 #8 0x41b30a68 in mozilla::ipc::MessagePump::Run (this=0x40402460, aDelegate=0x404310c0) at /home/sr/workspace1/B2G-2/B2G/gecko/ipc/glue/MessagePump.cpp:82 #9 0x41dec1fc in MessageLoop::RunInternal (this=0x404310c0) at /home/sr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:216 #10 0x41dec1ce in MessageLoop::RunHandler (this=0x404310c0) at /home/sr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:209 #11 0x41dec176 in MessageLoop::Run (this=0x404310c0) at /home/sr/workspace1/B2G-2/B2G/gecko/ipc/chromium/src/base/message_loop.cc:183 #12 0x41a2a79e in nsBaseAppShell::Run (this=0x404b68e0) at /home/sr/workspace1/B2G-2/B2G/gecko/widget/xpwidgets/nsBaseAppShell.cpp:163 #13 0x418dc9c4 in nsAppStartup::Run (this=0x44271b20) at /home/sr/workspace1/B2G-2/B2G/gecko/toolkit/components/startup/nsAppStartup.cpp:290 #14 0x40c3423c in XREMain::XRE_mainRun (this=0xbec10990) at /home/sr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3794 #15 0x40c34470 in XREMain::XRE_main (this=0xbec10990, argc=1, argv=0xbec12ba4, aAppData=0x36180) at /home/sr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3860 #16 0x40c34606 in XRE_main (argc=1, argv=0xbec12ba4, aAppData=0x36180, aFlags=0) at /home/sr/workspace1/B2G-2/B2G/gecko/toolkit/xre/nsAppRunner.cpp:3935 #17 0x00009d5c in do_main (argc=1, argv=0xbec12ba4) at /home/sr/workspace1/B2G-2/B2G/gecko/b2g/app/nsBrowserApp.cpp:168 #18 0x0000a02a in main (argc=1, argv=0xbec12ba4) at /home/sr/workspace1/B2G-2/B2G/gecko/b2g/app/nsBrowserApp.cpp:261 Program received signal SIGSEGV, Segmentation fault. 0x4005ab78 in jemalloc_crash () at /home/sr/workspace1/B2G-2/B2G/gecko/memory/mozjemalloc/jemalloc.c:1582 1582 MOZ_CRASH();
Comment on attachment 743014 [details] [diff] [review] Bug 858436 Review of attachment 743014 [details] [diff] [review]: ----------------------------------------------------------------- f- since we should return false rather than true and then the DOM request will be returned afterwards. If true is returned here, the DOM request will never be replied. It seems like that we receive a new connect request before the socket status becomes CONNECTING/CONNECTED, so we failed to refuse the new connect request and then reset mRunnable. As a result, mRunnable might had been freed before OnConnectError() was invoked.
Attachment #743014 - Flags: feedback?(gyeh) → feedback-
Attachment #743014 - Attachment is obsolete: true
Attachment #743014 - Flags: feedback?(echou)
Attached patch trial fix (obsolete) — — Splinter Review
Attachment #743472 - Flags: feedback?(gyeh)
Attachment #743472 - Flags: feedback?(echou)
Comment on attachment 743472 [details] [diff] [review] trial fix Review of attachment 743472 [details] [diff] [review]: ----------------------------------------------------------------- We could combine it with the below socket status checking, right? e.g. if (s == SocketConnectionStatus::SOCKET_CONNECTED || s == SocketConnectionStatus::SOCKET_CONNECTING) { ... We can add a new data member, like mIsConnecting, to indicate that we're in the process of creating a socket, and check mIsConnecting in the above if condition. (Reset mIsConnecting in both OnConnectSuccess and OnConnectError) Or, since mIsConnecting is not used in any other places, we can just check mRunnable in the above if condition (and no need to keep a data member). However, in this way, it's not easy to read, it would be better to add some comments to explain why we need to check mRunnable.
Attachment #743472 - Flags: feedback?(gyeh)
Hello Eric, the reason i added this check is because BluetoothHfpManager::Connect(), mRunnable will be assigned whenever connect had been called.
Comment on attachment 743472 [details] [diff] [review] trial fix Review of attachment 743472 [details] [diff] [review]: ----------------------------------------------------------------- Based on Shawn's comment, let me describe how this happened: "It happens when BluetoothHfpManager::Connect() is called more than once in a very short period of time. In this case, mRunnable would be assigned even if it has value. That would release a reference to the old runnable instance, but the old runnable may be still used on another thread such as GetSocketViaService()." The solution is clear: we shouldn't let mRunnable be assigned unless it has no value. This happened with old build but cannot reproduce anymore with current build. I guess that's because the Connect/Disconnect/Listen mechanism of each Bluetooth*Manager has been changed since bug 851046 landed. Therefore, I prefer adding an assertion MOZ_ASSERT(!mRunnable) right before |mRunnable = aRunnable;| instead of returning false.
Attachment #743472 - Flags: feedback?(echou) → feedback-
As Eric's Comment 30 mentioned, after introducing patch for Bug 851046, in BluetoothHfpManager::Connect, new guard condition for mSocket was been added, so there is no chance to re-assign variable mRunnable, which fixes this problem, this explain question in Comment 22.
Attachment #743472 - Attachment is obsolete: true
Attachment #743472 - Flags: feedback-
Resolving worksforme based on comments #22 & #31.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Clean leo+ flag based on Comment 22, Comment 31
blocking-b2g: leo+ → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: