Closed Bug 870444 Opened 12 years ago Closed 8 years ago

If a process crashes while it's holding a wake lock that another process holds alive, we may incorrectly notify observers of a wakelock changed event

Categories

(Firefox OS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: justin.lebar+bug, Unassigned)

Details

As I read HalWakeLock::RemoveChildFromList, here's what I think can happen. * Process A holds wake lock L * Process B holds wake lock L * Process C has wake lock listeners registered * Process A crashes * We run RemoveChildFromList(aKey="L") * sActiveListeners > 0 * We NotifyWakeLockChange(info.topic() == "L") * Process C gets a wakelock change notification, even though L is still locked. This is an edge case, but it's still a bug. :) We should try to write a testcase, if we can. I think it's possible to crash a process from mochitest.
Another bug here that I'll probably fix in bug 870203 is that we don't send along the list of locking process IDs in this particular WakeLockInformation. Which is quite bad.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.