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.

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 --------------------------------------------------

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

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

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

[Blocking Requested - why for this release]: Reproducible crash and a regression so nominating this 2.5?

Andrew, I think we need some DOM help here. The stack is in the description.

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.

Jocelyn, can you take a look at this please? Looks like this was caused by the landing for bug 1167064.

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.

(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

QA-Wanted to get a video

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

(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.

ni myself as a reminder

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 ======

|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

Redirect to Bruce, he did investigation on this bug.

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?

Comment on attachment 8636447 [details] [diff] [review] bug1176898_disconnect_event_target_object_crash.patch Review of attachment 8636447 [details] [diff] [review]: ----------------------------------------------------------------- LGTM.

(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. :-)

Treeherder results seem good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4f5a294be616