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)
Firefox OS Graveyard
General
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.
| Reporter | ||
Comment 1•12 years ago
|
||
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.
Comment 2•8 years ago
|
||
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.
Description
•