Closed Bug 992313 Opened 10 years ago Closed 10 years ago

Crash in ContentChild::RecvNotifyIdleObserver while running stability scripts

Categories

(Core :: IPC, defect)

30 Branch
ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

()

RESOLVED FIXED
1.4 S6 (25apr)
blocking-b2g 1.4+
Tracking Status
firefox29 --- wontfix
firefox30 --- fixed
firefox31 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: ggrisco, Assigned: reuben)

Details

(Keywords: crash, Whiteboard: [caf-crash 137][caf priority: p1][CR 643545][b2g-crash][systemsfe])

Crash Data

Attachments

(4 files)

1. Run a script with the following test cases: Call, SMS, Music, Camera, Camcorder, Video, Browser, FM on.off, Airplanemode on/off, BT on/off and WIFI on/off
2. After night run, mini dumps are generated in the phone.

[@ mozilla::dom::ContentChild::RecvNotifyIdleObserver(unsigned long long const&, nsCString const&, nsString const&) | mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) | mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) | mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ]
Attached file EXTRA file attachment
Logs are attached to the .EXTRA file

We have seen this crash a total of 4 times so far.
gaia sha1: 7e705dd4718d528974d99ac31866318d7e201152
gecko sha1: 81826931597f4b330cf2d6c40f444bcce000a6b8
Component: General → IPC
Keywords: crash
Product: Firefox OS → Core
Whiteboard: [CR 643545] → [CR 643545][b2g-crash]
Version: unspecified → 30 Branch
Hey Ben?  Could you help find someone to look at this crash please?  I'm not sure who to contact for this.
Flags: needinfo?(bent.mozilla)
Reuben, it looks like someone is deleting your idle observer out from under you. Not sure how that can happen, but you must have an addref/release mismatch somewhere.
Flags: needinfo?(bent.mozilla)
Negative stability impact = 1.4+
blocking-b2g: 1.4? → 1.4+
Hi, Andrew, looks like you're the engineering manager for IPC component(please correct me if I am wrong), could you help to find someone to work on this bug? Thank you!
Flags: needinfo?(overholt)
I suspect Reuben will take this but don't want to just assign (I'll leave that to Gregor).
Flags: needinfo?(reuben.bmo)
Flags: needinfo?(overholt)
Flags: needinfo?(anygregor)
Yes. The reason why I haven't taken this yet is a specially nasty exam that I'll take tomorrow :)
Assignee: nobody → reuben.bmo
Status: NEW → ASSIGNED
Flags: needinfo?(reuben.bmo)
Flags: needinfo?(anygregor)
(In reply to Reuben Morais [:reuben] from comment #8)
> Yes. The reason why I haven't taken this yet is a specially nasty exam that
> I'll take tomorrow :)

Thank you, Reuben and Andrew!
Whiteboard: [CR 643545][b2g-crash] → [CR 643545][b2g-crash][systemsfe]
Target Milestone: --- → 1.4 S6 (25apr)
I think this is happening when someone unregisters an idle observer right before it fires in the parent. We release the observer when unregistering it, then we receive an idle notification and call bad_pointer->Observe.
I had to do some silly things to reproduce this crash. Call navigator.addIdleObserver to trigger it: https://people.mozilla.org/~rmorais/i.html
Comment on attachment 8408988 [details] [diff] [review]
Keep track of registered idle observers in a set

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

Good catch!
Attachment #8408988 - Flags: review?(roc) → review+
https://hg.mozilla.org/mozilla-central/rev/dc037e7f4228
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 8408988 [details] [diff] [review]
Keep track of registered idle observers in a set

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

::: dom/ipc/ContentChild.cpp
@@ +1280,5 @@
>      }
>  
>      mAlertObservers.Clear();
>  
> +    mIdleObservers.Clear();

Hm, anything in this set has a reference added, right? Clearing here won't call release on it, so won't this cause leaks?
(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #17)
> Hm, anything in this set has a reference added, right?

Yes, but not because of it being in the set, we AddRef in AddIdleObserver and Release in RemoveIdleObserver.
Whiteboard: [CR 643545][b2g-crash][systemsfe] → [caf priority: p1][CR 643545][b2g-crash][systemsfe]
Observed on: 

Device: 
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.066
Moz BuildID: 20140331000202
B2G Version: 1.4
Gecko Version: 30.0a2
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=4c3b2f57f4229c5f36f0d8fd399e65f4db88f104
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=d02b9250ef7fedafc6c709dfcc899844b8624ab6
Are we sure this most recent crash observation is of the same bug?
Flags: needinfo?(ggrisco)
(In reply to Andrew Overholt [:overholt] from comment #20)
> Are we sure this most recent crash observation is of the same bug?

Sorry for the bz spam.  :cafbot was just reporting the last time this crash was observed, which was prior to picking up the fix here.  This is a one-time event (hopefully!)
Flags: needinfo?(ggrisco)
Whiteboard: [caf priority: p1][CR 643545][b2g-crash][systemsfe] → [caf-crash 137][caf priority: p1][CR 643545][b2g-crash][systemsfe]
Flags: in-moztrap?(ychung)
Not enough information on this bug to create a valid test case
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(ychung)
Flags: in-moztrap-
You need to log in before you can comment on or make changes to this bug.