Closed Bug 1135113 Opened 9 years ago Closed 9 years ago

OS.File requests may be lost on b2g due to _worker lifetime coordination issue/race (on queue management), especially on (slow) b2g emulator builds

Categories

(Toolkit Graveyard :: OS.File, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1125989

People

(Reporter: asuth, Unassigned)

Details

In bug 979446 with mochitest runs on b2g emulator debug builds (which are absurdly slow), the following sequence of OS.File calls:

- writeAtomic
(time passes)
- stat

is ending up with the following messages sent to the worker, per debug tracing:
- OS Controller Posting message {"fun":"writeAtomic","args":[{"string":"/data/local/tests/profile/downloads.json"},{"data":"[Uint8Array 0 312]"},{"tmpPath":{"string":"/data/local/tests/profile/downloads.json.tmp"},"bytes":312}],"id":1}
- OS Controller Posting message {"fun":"Meta_shutdown","args":[true],"id":2}
- OS Controller Posting message {"fun":"stat","args":[{"string":"/storage/sdcard/ALMOST CERTAINLY DOES NOT EXIST"},null],"id":3}

The "stat" call is never resolved.  Which makes sense because we're sending it after we tell the worker to shutdown.

The problem seems to be derived from the management of queue. kill()'s task waits for `queue` to complete before replacing `queue` with a deferred it controls.  This means that while kill() is waiting on queue, it is possible for another call to chain itself onto the "queue" promise chain (ex: my "stat" call).

When the pending queue command (writeAtomic) does complete, kill's task will then resume and invoke _worker.post.  But the "stat" post will then also get to run since it will also have been triggered by the resolution of queue.  As long as the shutdown takes some time, _worker will not yet be cleared and so the "stat" task will get a chance to post its request (which it will never receive a reply for).

I need to look into it more, but I expect the simplest solution is to make sure that kill() synchronously saves off 'queue' and replaces it with one it controls.
Almost sure that this is the same as bug 1125989.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
No longer blocks: 979446
Yes, it seems likely.  I did my dupe-checking based on the bugs in this component and google searching wasn't finding that bug.
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.