Closed Bug 1164100 Opened 5 years ago Closed 5 years ago

Service workers enabled app won't load after restarting b2g

Categories

(Core :: DOM: Service Workers, defect, major)

All
Gonk (Firefox OS)
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox39 --- unaffected
firefox40 --- fixed
firefox41 --- fixed

People

(Reporter: ferjm, Assigned: bkelly)

References

Details

(Whiteboard: [sw-most-wanted])

Attachments

(3 files)

STR:

1. Serve the content of the attached test application.
2. Navigate to the app from the b2g browser app.
3. You should see these logs on the logcat:

Service Worker service-worker-install
Service Worker service-worker-onactivate
...

4. adb reboot
5. Navigate to the app from the b2g browser app.

Expected:
6. The app should load and you should see in the logcat
Service Worker service-worker-onfetch

Current:
7. The app won't load and you can see this error in the logcat:

E/Browser ( 1661): [JavaScript Error: "Error: Failed to load script (nsresult = 0x80004005)"]

I've noticed that baseURL is empty at this point after rebooting b2g https://dxr.mozilla.org/mozilla-central/source/dom/fetch/Request.cpp?from=GetRequestURLFromWorker&case=true#113
Attached file testapp.zip
Blocks: 1161684
See Also: → 1164065
Whiteboard: [sw-most-wanted]
I get this output on a debug build:

I/Gecko   ( 1664): [Child 1664] WARNING: 'NS_FAILED(rv)', file ../../../dom/ipc/TabChild.cpp, line 1938
I/Gecko   ( 1664): [Child 1664] WARNING: Unable to printf the requested string due to error.: file ../../../ipc/chromium/src/base/string_util.cc, line 427
I/Gecko   (  205): [Parent 205] WARNING: Unknown directory found!: file ../../../dom/quota/QuotaManager.cpp, line 2080
I/Gecko   (  205): [Parent 205] WARNING: 'NS_FAILED(rv)', file ../../../dom/quota/QuotaManager.cpp, line 2009
I/Gecko   (  205): [Parent 205] WARNING: 'NS_FAILED(rv)', file ../../../dom/quota/QuotaManager.cpp, line 2336
I/Gecko   (  205): [Parent 205] WARNING: 'aRv.Failed()', file ../../../dom/cache/CacheOpParent.cpp, line 167
F/MOZ_Assert(  205): Assertion failure: mQuotaInfo.mDir, at ../../../dom/cache/Context.cpp:467
I/Gecko   ( 1664): [Child 1664] WARNING: 'aRv.Failed()', file ../../../dom/cache/CacheOpChild.cpp, line 100
F/libc    (  205): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 764 (IPDL Background)
E/Browser ( 1664): [JavaScript Error: "Error: Failed to load script (nsresult = 0x80004005)"]
I/DEBUG   (  196): unexpected waitpid response: n=764, status=00000b00
I/DEBUG   (  196): ptrace detach from 764 failed: No such process
I/DEBUG   (  196): debuggerd committing suicide to free the zombie!
I/DEBUG   ( 1688): debuggerd: Apr  9 2015 14:47:15
I/Gecko   ( 1664): [Child 1664] WARNING: 'NS_FAILED(rv)', file ../../../dom/base/URL.cpp, line 89
I/Gecko   ( 1664): [Child 1664] WARNING: 'aRv.Failed()', file ../../../dom/fetch/Request.cpp, line 112
I/Gecko   ( 1664): [Child 1664] WARNING: 'aRv.Failed()', file ../../../dom/fetch/Request.cpp, line 176
I/Gecko   ( 1664): [Child 1664] WARNING: 'result.Failed()', file ../../../dom/workers/ServiceWorkerManager.cpp, line 2692
F/MOZ_Assert( 1664): Assertion failure: !mMessage, at ../../dist/include/mozilla/ErrorResult.h:57
This is fallout from bug 1134671.
Assignee: nobody → bkelly
Blocks: 1134671
Status: NEW → ASSIGNED
The base directory being passed around in Cache was wrong when reusing the database directory.  This created the body directory in the wrong location which then failed in QM on next start.

Fernando, Doug, does this fix your problems?
Attachment #8605367 - Flags: review?(ehsan)
Attachment #8605367 - Flags: feedback?(ferjmoreno)
Attachment #8605367 - Flags: feedback?(dougt)
Note, you will need to wipe the storage directory after rebuilding with this patch for any origin you are hitting this problem on.
Comment on attachment 8605367 [details] [diff] [review]
Cache API should use correct base dir even when reusing sqlite connection. r=ehsan

works for me.
Attachment #8605367 - Flags: feedback?(dougt) → feedback+
Comment on attachment 8605367 [details] [diff] [review]
Cache API should use correct base dir even when reusing sqlite connection. r=ehsan

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

Yes, this solves the issue for me as well. Thanks!
Attachment #8605367 - Flags: feedback?(ferjmoreno) → feedback+
While the previous patch fixes the root cause triggering the QuotaManager failure, we should also fix the bogus assert triggering the crash in debug builds.

We used to be able to enforce the quota directory existence in ActionRunnable's constructor, but now we always send an ActionRunnable for NullAction when the Context shuts down.  This occurs even if QuotaInitRunnable failed.

Normal Actions will still assert that they are only run when QuotaInitRunnable succeeds and we have a quota dir.
Attachment #8605395 - Flags: review?(ehsan)
Duplicate of this bug: 1164524
Attachment #8605367 - Flags: review?(ehsan) → review+
Attachment #8605395 - Flags: review?(ehsan) → review+
Comment on attachment 8605367 [details] [diff] [review]
Cache API should use correct base dir even when reusing sqlite connection. r=ehsan

Approval Request Comment
[Feature/regressing bug #]: Regressed right before merge in bug 1134671
[User impact if declined]: Developers testing service workers will hit startup failures.  Important to get this before dev edition updates are turned on as it can leave a bad entry in the users profile.
[Describe test coverage new/current, TreeHerder]: SW Cache API has mochitests and web-platform-tests.
[Risks and why]: Minimal risk as this is a simple change.
[String/UUID change made/needed]: none
Attachment #8605367 - Flags: approval-mozilla-aurora?
Comment on attachment 8605395 [details] [diff] [review]
P2 Fix defunct assertion in Cache API ActionRunnable. r=ehsan

See entry for P1.
Attachment #8605395 - Flags: approval-mozilla-aurora?
Comment on attachment 8605367 [details] [diff] [review]
Cache API should use correct base dir even when reusing sqlite connection. r=ehsan

Thanks for being on top of this. Let's clean this up before we expose anyone to Aurora 40.
Attachment #8605367 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8605395 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/8d086111bebf
https://hg.mozilla.org/mozilla-central/rev/16da13eaaa02
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Duplicate of this bug: 1165339
You need to log in before you can comment on or make changes to this bug.