Closed Bug 1176898 Opened 5 years ago Closed 4 years ago

crash in DisconnectEventTargetObjects

Categories

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

Unspecified
Android
defect
Not set
critical

Tracking

(blocking-b2g:2.5+, firefox42 fixed, b2g-v2.2 unaffected, b2g-master fixed)

RESOLVED FIXED
FxOS-S3 (24Jul)
blocking-b2g 2.5+
Tracking Status
firefox42 --- fixed
b2g-v2.2 --- unaffected
b2g-master --- fixed

People

(Reporter: onelson, Assigned: brsun)

References

(Depends on 1 open bug)

Details

(Keywords: crash, regression, reproducible, Whiteboard: [3.0-Daily-Testing], [Spark])

Crash Data

Attachments

(3 files)

This bug was filed from the Socorro interface and is 
report bp-91d2358b-8ccc-4c42-b0b7-e32532150623.
=============================================================

Description:
Aries Device presented a crash report after listening to music from a hosted app (SoundCloud) and then proceeding to close every tab (about 10).

Repro Steps:
1) Update phone to 20150622125855 [flashed latest dogfood.debug, changed channel to dogfood-latest and updated)
2) .. Performing Smoketests.. [many tabs open]
3) Download SoundCloud App
4) Listen to SoundCloud
* 5) Close multiple tabs via task manager
* 6) Observe screen

Actual:
Phone presented crash report

Expected:
Phone returns to homescreen


Environmental Variables:
--------------------------------------------------

Device: Aries 3.0
BuildID: 20150622125855
Gaia: 311c4e59936a407e64509f54fecb440d8a78e3c8
Gecko: cddf3b36b5e2
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (3.0) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
--------------------------------------------------
Repro: Once

* crash likely related to closing tabs
Adding qawanted to find steps for this crash.
QA Whiteboard: [QAnalyst-Triage+]
Whiteboard: [3.0-Daily-Testing], [Spark], [systemsfe]
CrashID: bp-3397d25a-322e-45b6-8ef2-146bc2150625

Experienced this crash again on Aries; issue appears heavily related to closing tabs via Task Manager.

Repro Steps:
1) Update phone to 20150625095718 [had Full flashed to RC4 then OTA update to this id]
2) Open Multiple tabs
3) ... Browser testing via WiFi and Cell Data ...
4) Close multiple tabs via Card View
5) Observe Crash Report

Actual:
Crash appears on screen

Expected:
No crash report


Environmental Variables:
--------------------------------------------------

Device: Aries 3.0
BuildID: 20150625095718
Gaia: 038e917076271d304b906a41b4de670e505c67ae
Gecko: 0b2f5e8b7be5
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (3.0) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
--------------------------------------------------
Summary: [Spark] crash in DisconnectEventTargetObjects → [Aries] crash in DisconnectEventTargetObjects
I was unable to reproduce this issue after an hour of attempting by closing tabs.  Leaving the steps-wanted tag for others to try.

Environmental Variables:
Device: Aries 3.0
BuildID: 20150625095718
Gaia: 038e917076271d304b906a41b4de670e505c67ae
Gecko: 0b2f5e8b7be5
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (3.0) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
I hit this crash on the Experia today, following the same steps. Also unable to reproduce.

I am running a build that is a bit older:
Gaia-Rev        fcce826ab790d074e88e055ae7f2ab4fb0f01903
Gecko-Rev       8a8307ba002f07c6a36668c65f6f39083bd30703
Build-ID        20150619021036
Version         41.0a1
Device-Name     aries
FW-Release      4.4.2
FW-Incremental  eng.worker.20150619.015544
FW-Date         Fri Jun 19 01:55:53 UTC 2015
Bootloader      s1
I encountered this issue 4 times across two separate devices on the latest Flame build on both 319MB and 512MB memory.

Repro Steps:
1) Open the Settings app
2) Navigate to bluetooth and toggle 'visible to all'
3) Receive and send several pair requests (no requests accepted)
4) Long press the home button and swipe the settings app up to close the app.

Actual Result:
Presented with Crash Report over the home screen.

Expected Result:
App closes and user is returned to the homescreen without issue.

Environmental Variables:
Device: Flame 2.5
Build ID: 20150701010205
Gaia: 90ed5ebde89b6fc095524e47c59d5b8d192d3ff2
Gecko: 079b6f1ae1c3
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Summary: [Aries] crash in DisconnectEventTargetObjects → crash in DisconnectEventTargetObjects
I can confirm the STR on comment 6 reproduces the crash on Flame and Aries:

https://crash-stats.mozilla.com/report/index/32385942-2d65-4689-97ee-7032c2150702 (via Flame)
https://crash-stats.mozilla.com/report/index/55671290-5aa6-4847-a7e2-b2a982150702 (via Aries)

Repro rate is 3 out of 3 on Flame, 1 out of 1 on Aries. (for step 3 I received 2 pairing requests, then sent out 2 pairing requests. Hit cancel to pair on all dialogs. If on some cases the pairing request window doesn't show up and a notification shows instead, lock and unlock the phone will make it show the pairing request window)

---------

The issue does NOT reproduce on Flame 2.2 using STR at comment 6. Repro rate is 0/5.

Device: Flame 2.2
BuildID: 20150702002503
Gaia: bd386f346eb1591fddbc84bf034b22700e7e2a58
Gecko: f16c1125b9d6
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
[Blocking Requested - why for this release]:

Reproducible crash and a regression so nominating this 2.5?
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Contact: pcheng
Andrew, I think we need some DOM help here. The stack is in the description.
blocking-b2g: 2.5? → 2.5+
Flags: needinfo?(overholt)
Whiteboard: [3.0-Daily-Testing], [Spark], [systemsfe] → [3.0-Daily-Testing], [Spark]
b2g-inbound regression window:

Last Working
Device: Flame
BuildID: 20150615161319
Gaia: eecd9d2bb220e10792762fc274c910cb3febbd72
Gecko: 454b81979ce8
Version: 41.0a1 (2.5 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

First Broken
Device: Flame
BuildID: 20150615184622
Gaia: 4dfe2da502e4370c9670d5bc13a73d22fb37a785
Gecko: 9f468853e6c9
Version: 41.0a1 (2.5 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Last Working Gaia & First Broken Gecko - issue DOES repro
Gaia: eecd9d2bb220e10792762fc274c910cb3febbd72
Gecko: 9f468853e6c9

Last Working Gecko & First Broken Gaia - issue does NOT repro
Gaia: 4dfe2da502e4370c9670d5bc13a73d22fb37a785
Gecko: 454b81979ce8

Gecko pushlog:
http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=454b81979ce8&tochange=9f468853e6c9

Possibly caused by Bug 1167064.
Blocks: 1167064
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Jocelyn, can you take a look at this please? Looks like this was caused by the landing for bug 1167064.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(joliu)
The stack likely suggests that someone is not reference counting a subclass of DOMEventTargetHelper correctly, and that it is being prematurely deleted.
I'll take a look.
Flags: needinfo?(joliu)
(In reply to Pi Wei Cheng [:piwei] from comment #7)
> I can confirm the STR on comment 6 reproduces the crash on Flame and Aries:
> 
> https://crash-stats.mozilla.com/report/index/32385942-2d65-4689-97ee-
> 7032c2150702 (via Flame)
> https://crash-stats.mozilla.com/report/index/55671290-5aa6-4847-a7e2-
> b2a982150702 (via Aries)
> 
> Repro rate is 3 out of 3 on Flame, 1 out of 1 on Aries. (for step 3 I
> received 2 pairing requests, then sent out 2 pairing requests. Hit cancel to
> pair on all dialogs. If on some cases the pairing request window doesn't
> show up and a notification shows instead, lock and unlock the phone will
> make it show the pairing request window)
> 
> ---------
> 
> The issue does NOT reproduce on Flame 2.2 using STR at comment 6. Repro rate
> is 0/5.
> 
> Device: Flame 2.2
> BuildID: 20150702002503
> Gaia: bd386f346eb1591fddbc84bf034b22700e7e2a58
> Gecko: f16c1125b9d6
> Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
> Version: 37.0 (2.2) 
> Firmware Version: v18D-1
> User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Hi Pi Wei,

I couldn't reproduce the bug on m-c flame-kk, maybe I misunderstood the STR.
Is it possible to provide a video here?

Thanks,
Jocelyn
Flags: needinfo?(pcheng)
QA-Wanted to get a video
Keywords: qawanted
QA Contact: pcheng
Video of issue:

http://youtu.be/33ut_serO94

Both devices in the video are of the following environment:
Device: Flame
BuildID: 20150707010204
Gaia: e6506d68e01489b57616f8b74e8773f938ce62b3
Gecko: e7e69cc8c07b
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5 Master) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(pcheng)
Flags: needinfo?(joliu)
Flags: needinfo?(jmercado)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
(In reply to Pi Wei Cheng [:piwei] from comment #16)
> Video of issue:
> 
> http://youtu.be/33ut_serO94
> 
> Both devices in the video are of the following environment:
> Device: Flame
> BuildID: 20150707010204
> Gaia: e6506d68e01489b57616f8b74e8773f938ce62b3
> Gecko: e7e69cc8c07b
> Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
> Version: 42.0a1 (2.5 Master) 
> Firmware Version: v18D-1
> User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Thanks, I can reproduce the issue follow the video now.
And as the stack and Comment 8 suggests, looks like the event target might already been released when running DisconnectEventTargetObjects.
I will first investigate which event target cause this and update here later.
Flags: needinfo?(joliu)
ni myself as a reminder
Flags: needinfo?(brsun)
It seems the address of a deleted |BluetoothDiscoveryHandle| (0xaf10d480 in this case) is dereferenced by |DisconnectEventTargetObjects| within |nsGlobalWindow|.

====== LOGCAT ======
07-20 17:13:45.830  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf32dee0, DOMEventTargetHelper:0xaf32dee0)
07-20 17:13:52.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf71ba60, DOMEventTargetHelper:0xaf71ba60)
07-20 17:13:53.900  3621  3621 I brsun   : BluetoothDiscoveryHandle::~BluetoothDiscoveryHandle(this:0xaf304400, DOMEventTargetHelper:0xaf304400)
07-20 17:14:10.050  3621  3621 I brsun   : BluetoothDiscoveryHandle::~BluetoothDiscoveryHandle(this:0xaf10d480, DOMEventTargetHelper:0xaf10d480)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf7642e0, DOMEventTargetHelper:0xaf7642e0)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf32dee0, DOMEventTargetHelper:0xaf32dee0)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf32dc40, DOMEventTargetHelper:0xaf32dc40)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf734ac0, DOMEventTargetHelper:0xaf734ac0)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf32d0a0, DOMEventTargetHelper:0xaf32d0a0)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf28a700, DOMEventTargetHelper:0xaf28a700)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xafc8b100, DOMEventTargetHelper:0xafc8b100)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf2454c0, DOMEventTargetHelper:0xaf2454c0)
07-20 17:14:10.280  3621  3621 I brsun   : BluetoothDevice::~BluetoothDevice(this:0xaf1c54c0, DOMEventTargetHelper:0xaf1c54c0)
====== LOGCAT ======

====== Call Stack ======
Program received signal SIGSEGV, Segmentation fault.
0xb4f43496 in nsRefPtr (aRawPtr=0xaf10d480, this=<synthetic pointer>) at ../../dist/include/nsRefPtr.h:99
99	      mRawPtr->AddRef();
(gdb) bt
#0  0xb4f43496 in nsRefPtr (aRawPtr=0xaf10d480, this=<synthetic pointer>) at ../../dist/include/nsRefPtr.h:99
#1  DisconnectEventTargetObjects (aKey=<optimized out>, aClosure=0x0) at ../../../../mozilla-central-working/dom/base/nsGlobalWindow.cpp:1240
#2  0xb4f47cd4 in nsTHashtable<nsPtrHashKey<mozilla::DOMEventTargetHelper> >::EnumerateEntries (this=this@entry=0xb384896c, 
    aEnumFunc=0xb4f4348d <DisconnectEventTargetObjects(nsPtrHashKey<mozilla::DOMEventTargetHelper>*, void*)>, aUserArg=0x0) at ../../dist/include/nsTHashtable.h:219
#3  0xb4f5349e in CleanUp (this=0xb38487d0) at ../../../../mozilla-central-working/dom/base/nsGlobalWindow.cpp:1420
#4  nsGlobalWindow::CleanUp (this=0xb38487d0) at ../../../../mozilla-central-working/dom/base/nsGlobalWindow.cpp:1411
#5  0xb4f53658 in CleanUp (this=0xb3847ec0) at ../../../../mozilla-central-working/dom/base/nsGlobalWindow.cpp:1489
#6  nsGlobalWindow::CleanUp (this=0xb3847ec0) at ../../../../mozilla-central-working/dom/base/nsGlobalWindow.cpp:1411
#7  0xb4f53c1a in nsGlobalWindow::DetachFromDocShell (this=0xb3847ec0) at ../../../../mozilla-central-working/dom/base/nsGlobalWindow.cpp:2930
#8  0xb58b0ea0 in nsDocShell::Destroy (this=0xb1763000) at /home/bruce_sun/Source/mozilla-central-working/docshell/base/nsDocShell.cpp:5854
#9  0xb58cb4ee in nsWebBrowser::SetDocShell (this=this@entry=0xb0b157a0, aDocShell=aDocShell@entry=0x0) at /home/bruce_sun/Source/mozilla-central-working/embedding/browser/nsWebBrowser.cpp:1654
#10 0xb58ccebe in nsWebBrowser::InternalDestroy (this=this@entry=0xb0b157a0) at /home/bruce_sun/Source/mozilla-central-working/embedding/browser/nsWebBrowser.cpp:95
#11 0xb58ccef4 in nsWebBrowser::Destroy (this=0xb0b157a0) at /home/bruce_sun/Source/mozilla-central-working/embedding/browser/nsWebBrowser.cpp:1275
#12 0xb556adde in mozilla::dom::TabChild::DestroyWindow (this=this@entry=0xb1762800) at /home/bruce_sun/Source/mozilla-central-working/dom/ipc/TabChild.cpp:1669
#13 0xb556af44 in mozilla::dom::TabChild::RecvDestroy (this=0xb1762800) at /home/bruce_sun/Source/mozilla-central-working/dom/ipc/TabChild.cpp:2901
#14 0xb4d0333c in mozilla::dom::PBrowserChild::OnMessageReceived (this=0xb1762974, msg__=...) at PBrowserChild.cpp:3773
#15 0xb4d415d0 in mozilla::dom::PContentChild::OnMessageReceived (this=0xb2dc0c18, msg__=...) at PContentChild.cpp:5333
#16 0xb4c4a17c in mozilla::ipc::MessageChannel::DispatchAsyncMessage (this=0xb2dc0c50, aMsg=...) at /home/bruce_sun/Source/mozilla-central-working/ipc/glue/MessageChannel.cpp:1373
#17 0xb4c4e774 in mozilla::ipc::MessageChannel::DispatchMessage (this=this@entry=0xb2dc0c50, aMsg=...) at /home/bruce_sun/Source/mozilla-central-working/ipc/glue/MessageChannel.cpp:1293
#18 0xb4c503b6 in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=0xb2dc0c50) at /home/bruce_sun/Source/mozilla-central-working/ipc/glue/MessageChannel.cpp:1264
#19 0xb4acad90 in DispatchToMethod<FdWatcher, void (FdWatcher::*)()> (method=(void (FdWatcher::*)(FdWatcher * const)) 0xb4c5035b <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, obj=<optimized out>, 
    arg=...) at ../../../../mozilla-central-working/ipc/chromium/src/base/tuple.h:387
#20 RunnableMethod<FdWatcher, void (FdWatcher::*)(), Tuple0>::Run (this=<optimized out>) at ../../../../mozilla-central-working/ipc/chromium/src/base/task.h:310
#21 0xb4c4898e in Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:456
#22 mozilla::ipc::MessageChannel::DequeueTask::Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:473
#23 0xb4c3c75c in MessageLoop::RunTask (this=0xbea2f108, task=0xaf1d2120) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:364
#24 0xb4c3ee32 in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=...) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:372
#25 0xb4c40a78 in DoWork (this=<optimized out>) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:459
#26 MessageLoop::DoWork (this=0xbea2f108) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:438
#27 0xb4c490ec in mozilla::ipc::DoWorkRunnable::Run (this=<optimized out>) at /home/bruce_sun/Source/mozilla-central-working/ipc/glue/MessagePump.cpp:220
#28 0xb4af0a94 in ProcessNextEvent (aResult=0xbea2f00f, aMayWait=<optimized out>, this=0xb6a025c0) at /home/bruce_sun/Source/mozilla-central-working/xpcom/threads/nsThread.cpp:867
#29 nsThread::ProcessNextEvent (this=0xb6a025c0, aMayWait=<optimized out>, aResult=0xbea2f00f) at /home/bruce_sun/Source/mozilla-central-working/xpcom/threads/nsThread.cpp:752
#30 0xb4b012ee in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=aMayWait@entry=true) at /home/bruce_sun/Source/mozilla-central-working/xpcom/glue/nsThreadUtils.cpp:277
#31 0xb4c4b65a in mozilla::ipc::MessagePump::Run (this=0xb6a55670, aDelegate=0xbea2f108) at /home/bruce_sun/Source/mozilla-central-working/ipc/glue/MessagePump.cpp:127
#32 0xb4c3c6e8 in MessageLoop::RunInternal (this=this@entry=0xbea2f108) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:234
#33 0xb4c3c79c in RunHandler (this=0xbea2f108) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:227
#34 MessageLoop::Run (this=0xbea2f108) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:201
#35 0xb562bd5a in nsBaseAppShell::Run (this=0xb18ef220) at /home/bruce_sun/Source/mozilla-central-working/widget/nsBaseAppShell.cpp:165
#36 0xb59a47f6 in XRE_RunAppShell () at ../../../../mozilla-central-working/toolkit/xre/nsEmbedFunctions.cpp:785
#37 0xb4c3c6e8 in MessageLoop::RunInternal (this=this@entry=0xbea2f108) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:234
#38 0xb4c3c79c in RunHandler (this=0xbea2f108) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:227
#39 MessageLoop::Run (this=this@entry=0xbea2f108) at /home/bruce_sun/Source/mozilla-central-working/ipc/chromium/src/base/message_loop.cc:201
#40 0xb59a4cca in XRE_InitChildProcess (aArgc=<optimized out>, aArgv=<optimized out>, aGMPLoader=<optimized out>) at ../../../../mozilla-central-working/toolkit/xre/nsEmbedFunctions.cpp:621
#41 0xb4d57d14 in content_process_main (argc=8, argc@entry=9, argv=argv@entry=0xb6a55460) at ../../../../mozilla-central-working/ipc/contentproc/plugin-container.cpp:236
#42 0xb4c4c9aa in mozilla::ipc::ProcLoaderLoadRunner::DoWork (this=<optimized out>) at /home/bruce_sun/Source/mozilla-central-working/ipc/glue/ProcessUtils_linux.cpp:434
#43 0xb4c4cb4e in ProcLoaderServiceRun (aReservedFds=..., aArgv=<optimized out>, aArgc=1, aFd=<optimized out>, aPeerPid=211)
    at /home/bruce_sun/Source/mozilla-central-working/ipc/glue/ProcessUtils_linux.cpp:593
#44 XRE_ProcLoaderServiceRun (aPeerPid=211, aFd=<optimized out>, aArgc=1, aArgv=<optimized out>, aReservedFds=...) at /home/bruce_sun/Source/mozilla-central-working/ipc/glue/ProcessUtils_linux.cpp:627
#45 0xb6fb96a2 in RunProcesses (aReservedFds=..., argv=0xbea2fc84, argc=1) at ../../../../mozilla-central-working/b2g/app/B2GLoader.cpp:219
#46 main (argc=1, argv=0xbea2fc84) at ../../../../mozilla-central-working/b2g/app/B2GLoader.cpp:297
====== Call Stack ======
Flags: needinfo?(brsun)
|BluetoothDiscoveryHandle| is directly derived from |DOMEventTargetHelper|. Generally speaking, an instance of |DOMEventTargetHelper| will be added in |nsGlobalWindow.mEventTargetObjects| during its construction[1], and it will be removed from that hash table during its desctuction[2].

In |BluetoothAdapter::SetDiscoveryHandleInUse|, |BluetoothDiscoveryHandle::DisconnectFromOwner|[3] is called explicitly. Since |DOMEventTargetHelper::mOwnerWindow|[4] is clear at this moment, the instance of |DOMEventTargetHelper| doesn't has chances to be removed from |nsGlobalWindow.mEventTargetObjects|.

The solution might be simple. If we don't trigger |DOMEventTargetHelper::DisconnectFromOwner| explicitly, we can always have a good tracking of the instance of |DOMEventTargetHelper| in |nsGlobalWindow.mEventTargetObjects|.

[1] https://dxr.mozilla.org/mozilla-central/source/dom/events/DOMEventTargetHelper.cpp#124
[2] https://dxr.mozilla.org/mozilla-central/source/dom/events/DOMEventTargetHelper.cpp#88
[3] https://dxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluetooth2/BluetoothAdapter.cpp#514
[4] https://dxr.mozilla.org/mozilla-central/source/dom/events/DOMEventTargetHelper.cpp#157
Attachment #8636447 - Flags: review?(btian)
Redirect to Bruce, he did investigation on this bug.
Assignee: shuang → brsun
Hmm, I guess there's no way to hide DisconnectFromOwner from everyone but nsGlobalWindow since subclasses can change the visibility when they override it.  Any bright ideas here?
Flags: needinfo?(ehsan)
Component: Gaia::System::Task Manager → Bluetooth
Comment on attachment 8636447 [details] [diff] [review]
bug1176898_disconnect_event_target_object_crash.patch

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

LGTM.
Attachment #8636447 - Flags: review?(btian) → review+
Depends on: 1186007
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) (UTC+8 July 17-25, expect delays) from comment #22)
> Hmm, I guess there's no way to hide DisconnectFromOwner from everyone but
> nsGlobalWindow since subclasses can change the visibility when they override
> it.

Yep.

> Any bright ideas here?

See bug 1186007.  :-)
Flags: needinfo?(ehsan)
https://hg.mozilla.org/mozilla-central/rev/e5c31a5932b6
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S3 (24Jul)
You need to log in before you can comment on or make changes to this bug.