Closed Bug 1392408 Opened 7 years ago Closed 5 years ago

Stack trace doesn't exist in 'cause' for XHR requests initiated by Workers

Categories

(DevTools :: Netmonitor, enhancement, P3)

Product:
DevTools
Component:
Netmonitor
Type:
enhancement

Tracking

(firefox57 fix-optional)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox57 --- fix-optional

People

(Reporter: bgrins, Assigned: bhackett1024)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [debugger-mvp] leave-open)

Attachments

(7 files, 1 obsolete file)

patch
51.66 KB, patch
Details | Diff | Splinter Review
Bug 1392408 Part 1 - Add interface to help convert SavedFrames to JSON, r=jimb.
47 bytes, text/x-phabricator-request
Details | Review
Bug 1392408 Part 2 - Encapsulate threadsafe main/worker stacks in WorkerStackHolder, r=bzbarsky.
47 bytes, text/x-phabricator-request
Details | Review
Bug 1392408 Part 3 - Report stacks to net monitor when loading worker scripts, r=bzbarsky.
47 bytes, text/x-phabricator-request
Details | Review
Bug 1392408 Part 4 - Report stacks to net monitor when opening XHRs from worker, r=bzbarsky.
47 bytes, text/x-phabricator-request
Details | Review
Bug 1392408 Part 5 - Listen for alternate stack traces in StackTraceCollector, r=jryans.
47 bytes, text/x-phabricator-request
Details | Review
Bug 1392408 Part 6 - Add test for capturing worker stacks in net monitor, r=jryans.
47 bytes, text/x-phabricator-request
Details | Review 
When a WebWorker does an XHR request or fetch, we don't get the normal 'JS' icon and 'stack trace' tab in the Network Monitor.
Product: Firefox → DevTools
Blocks: dbg-stacks

(In reply to Brian Grinstead [:bgrins] from comment #0)

When a WebWorker does an XHR request or fetch, we don't get the normal 'JS'
icon and 'stack trace' tab in the Network Monitor.

I can still see that the 'Stack Trace' side panel is missing.

@Brian: what do you mean by the 'JS' icon? Is it still valid issue?

Honza

Flags: needinfo?(bgrinstead)

I think I was referring to the "type" column (which IIRC used to show up as more of a badge/icon). Wish I would have included a screenshot and demo page when filing this, though. Can you link to whatever test case you used to confirm the Stack Trace panel is missing?

Flags: needinfo?(bgrinstead) → needinfo?(odvarko)

STR:

  1. Load http://janodvarko.cz/tests/bugzilla/1392408/
  2. Open the Network panel and click Simple XHR button on the page. This button generates XHR (from the main thread)
  3. Select the request and check the Stack Trace tab in the side panel -> should be OK
  4. Click Start Worker button
  5. There is immediate request for the worker script, check the side bar for stack trace, it's missing -> BUG
  6. Wait for 5 sec there is another XHR done from within the worker, check the side bar for stack trace, it's missing -> BUG

Brian can you repro that using this test case?

Honza

Flags: needinfo?(odvarko) → needinfo?(bgrinstead)

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #3)

STR:

  1. Load http://janodvarko.cz/tests/bugzilla/1392408/
  2. Open the Network panel and click Simple XHR button on the page. This button generates XHR (from the main thread)
  3. Select the request and check the Stack Trace tab in the side panel -> should be OK
  4. Click Start Worker button
  5. There is immediate request for the worker script, check the side bar for stack trace, it's missing -> BUG
  6. Wait for 5 sec there is another XHR done from within the worker, check the side bar for stack trace, it's missing -> BUG

Brian can you repro that using this test case?

Thanks. I can reproduce the missing stack trace in both cases you mention. Forget the part about "js icon" in Comment 0, I don't see anything related to that anymore.

Flags: needinfo?(bgrinstead)

Brian, is this easy to fix?

Note that the Network monitor is using StackTraceCollector to collect the list of frames for HTTP requests.

https://searchfox.org/mozilla-central/rev/a7315d78417179b151fef6108f2bce14786ba64d/devtools/server/actors/network-monitor/stack-trace-collector.js#19

Honza

Flags: needinfo?(bhackett1024)

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #3)

  1. There is immediate request for the worker script, check the side bar for stack trace, it's missing -> BUG
  2. Wait for 5 sec there is another XHR done from within the worker, check the side bar for stack trace, it's missing -> BUG

Both of these have the same underlying cause. When a worker makes an HTTP request (for either its own .js file or for an XHR) it does so by dispatching runnables to the main thread to open the channel, triggering the observer in StackTraceCollector when there is nothing on the main thread's stack. The associated C++ stacks are below, for reference. I don't think either of these cases is super easy to fix: StackFrameCollector only operates on the main thread's current stack, and in both of these cases we need to save the stack somewhere else while we're in C++ and hand it off later for processing.

I'll look more closely at fixing this soon, but doing bug 1543751 first will give some insights into managing stack traces while we're on a worker thread.

Worker Script

* frame #0: 0x000000011c3d67f0 XUL`Interpret(cx=<unavailable>, state=<unavailable>) at Interpreter.cpp:1961 [opt]
    frame #1: 0x000000011c3d5abc XUL`js::RunScript(cx=0x000000010d527000, state=0x00007ffee60efd50) at Interpreter.cpp:422 [opt]
    frame #2: 0x000000011c3e58b9 XUL`js::InternalCallOrConstruct(cx=0x000000010d527000, args=0x00007ffee60efdf8, construct=<unavailable>) at Interpreter.cpp:562 [opt]
    frame #3: 0x000000011c3e5df9 XUL`js::Call(cx=<unavailable>, fval=<unavailable>, thisv=<unavailable>, args=0x00007ffee60efdf8, rval=<unavailable>) at Interpreter.cpp:605 [opt]
    frame #4: 0x000000011c7547de XUL`JS_CallFunctionValue(cx=0x000000010d527000, obj=<unavailable>, fval=<unavailable>, args=0x00007ffee60effc8, rval=JS::MutableHandleValue @ 0x00007ffee60efde0) at jsapi.cpp:2558 [opt]
    frame #5: 0x000000011908ea19 XUL`nsXPCWrappedJSClass::CallMethod(wrapper=<unavailable>, methodIndex=<unavailable>, info=<unavailable>, nativeParams=0x00007ffee60f0360) at XPCWrappedJSClass.cpp:951 [opt]
    frame #6: 0x00000001187e0175 XUL`::PrepareAndDispatch(self=0x0000000116677ec0, methodIndex=<unavailable>, args=<unavailable>, gpregs=0x00007ffee60f0420, fpregs=0x00007ffee60f0450) at xptcstubs_x86_64_darwin.cpp:129 [opt]
    frame #7: 0x00000001187def9b XUL`SharedStub + 91
    frame #8: 0x0000000118761d6f XUL`nsObserverList::NotifyObservers(this=<unavailable>, aSubject=0x0000000116624800, aTopic="http-on-opening-request", someData=0x0000000000000000) at nsObserverList.cpp:66 [opt]
    frame #9: 0x0000000118763b1c XUL`nsObserverService::NotifyObservers(this=<unavailable>, aSubject=0x0000000116624800, aTopic="http-on-opening-request", aSomeData=0x0000000000000000) at nsObserverService.cpp:294 [opt]
    frame #10: 0x0000000118b36330 XUL`mozilla::net::nsHttpHandler::NotifyObservers(this=<unavailable>, chan=0x0000000116624800, event="http-on-opening-request") at nsHttpHandler.cpp:835 [opt]
    frame #11: 0x0000000118b8009b XUL`mozilla::net::HttpChannelChild::AsyncOpen(nsIStreamListener*) [inlined] mozilla::net::nsHttpHandler::OnOpeningRequest(this=<unavailable>, chan=0x0000000116624800) at nsHttpHandler.h:329 [opt]
    frame #12: 0x0000000118b80085 XUL`mozilla::net::HttpChannelChild::AsyncOpen(this=0x0000000116624800, aListener=<unavailable>) at HttpChannelChild.cpp:2488 [opt]
    frame #13: 0x000000011ac78db3 XUL`mozilla::dom::(anonymous namespace)::ScriptLoaderRunnable::LoadScript(this=<unavailable>, aIndex=360613824) at ScriptLoader.cpp:988 [opt]
    frame #14: 0x000000011ac77dce XUL`mozilla::dom::(anonymous namespace)::ScriptLoaderRunnable::Run() at ScriptLoader.cpp:842 [opt]
    frame #15: 0x000000011ac77d55 XUL`mozilla::dom::(anonymous namespace)::ScriptLoaderRunnable::Run(this=0x00000001166b8430) at ScriptLoader.cpp:598 [opt]
    frame #16: 0x00000001187ceee1 XUL`nsThread::ProcessNextEvent(this=0x000000010a04eac0, aMayWait=<unavailable>, aResult=0x00007ffee60f0d9f) at nsThread.cpp:1180 [opt]
    frame #17: 0x00000001187d1669 XUL`NS_ProcessNextEvent(aThread=<unavailable>, aMayWait=false) at nsThreadUtils.cpp:486 [opt]
    frame #18: 0x0000000118d1b156 XUL`mozilla::ipc::MessagePump::Run(this=0x000000010a05e6f0, aDelegate=0x00007ffee60f0fb8) at MessagePump.cpp:88 [opt]
    frame #19: 0x0000000118cd9809 XUL`MessageLoop::Run() [inlined] MessageLoop::RunInternal(this=<unavailable>) at message_loop.cc:315 [opt]
    frame #20: 0x0000000118cd97fa XUL`MessageLoop::Run() [inlined] MessageLoop::RunHandler(this=<unavailable>) at message_loop.cc:308 [opt]
    frame #21: 0x0000000118cd97fa XUL`MessageLoop::Run(this=<unavailable>) at message_loop.cc:290 [opt]
    frame #22: 0x000000011aee0e29 XUL`nsBaseAppShell::Run(this=0x000000010ba50310) at nsBaseAppShell.cpp:137 [opt]
    frame #23: 0x000000011af4b4cf XUL`nsAppShell::Run(this=0x000000010ba50310) at nsAppShell.mm:702 [opt]
    frame #24: 0x000000011c304cb8 XUL`XRE_RunAppShell() at nsEmbedFunctions.cpp:919 [opt]
    frame #25: 0x0000000118cd9809 XUL`MessageLoop::Run() [inlined] MessageLoop::RunInternal(this=<unavailable>) at message_loop.cc:315 [opt]
    frame #26: 0x0000000118cd97fa XUL`MessageLoop::Run() [inlined] MessageLoop::RunHandler(this=<unavailable>) at message_loop.cc:308 [opt]
    frame #27: 0x0000000118cd97fa XUL`MessageLoop::Run(this=<unavailable>) at message_loop.cc:290 [opt]
    frame #28: 0x000000011c304a5a XUL`XRE_InitChildProcess(aArgc=<unavailable>, aArgv=<unavailable>, aChildData=<unavailable>) at nsEmbedFunctions.cpp:757 [opt]
    frame #29: 0x0000000109b0ef07 plugin-container`main [inlined] content_process_main(bootstrap=0x000000010a00b180, argc=<unavailable>, argv=0x00007ffee60f1248) at plugin-container.cpp:56 [opt]
    frame #30: 0x0000000109b0eedb plugin-container`main(argc=<unavailable>, argv=0x00007ffee60f1248) at MozillaRuntimeMain.cpp:23 [opt]
    frame #31: 0x00007fff5a74d085 libdyld.dylib`start + 1
    frame #32: 0x00007fff5a74d085 libdyld.dylib`start + 1

Worker XHR request

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x0000000113d191e4 XUL`Interpret(cx=<unavailable>, state=<unavailable>) at Interpreter.cpp:0 [opt]
    frame #1: 0x0000000113d17abc XUL`js::RunScript(cx=0x000000010eb27000, state=0x00007ffee4b18a00) at Interpreter.cpp:422 [opt]
    frame #2: 0x0000000113d278b9 XUL`js::InternalCallOrConstruct(cx=0x000000010eb27000, args=0x00007ffee4b18aa8, construct=<unavailable>) at Interpreter.cpp:562 [opt]
    frame #3: 0x0000000113d27df9 XUL`js::Call(cx=<unavailable>, fval=<unavailable>, thisv=<unavailable>, args=0x00007ffee4b18aa8, rval=<unavailable>) at Interpreter.cpp:605 [opt]
    frame #4: 0x00000001140967de XUL`JS_CallFunctionValue(cx=0x000000010eb27000, obj=<unavailable>, fval=<unavailable>, args=0x00007ffee4b18c78, rval=JS::MutableHandleValue @ 0x00007ffee4b18a90) at jsapi.cpp:2558 [opt]
    frame #5: 0x00000001109d0a19 XUL`nsXPCWrappedJSClass::CallMethod(wrapper=<unavailable>, methodIndex=<unavailable>, info=<unavailable>, nativeParams=0x00007ffee4b19010) at XPCWrappedJSClass.cpp:951 [opt]
    frame #6: 0x0000000110122175 XUL`::PrepareAndDispatch(self=0x000000012873dc60, methodIndex=<unavailable>, args=<unavailable>, gpregs=0x00007ffee4b190d0, fpregs=0x00007ffee4b19100) at xptcstubs_x86_64_darwin.cpp:129 [opt]
    frame #7: 0x0000000110120f9b XUL`SharedStub + 91
    frame #8: 0x00000001100a3d6f XUL`nsObserverList::NotifyObservers(this=<unavailable>, aSubject=0x000000012871f000, aTopic="http-on-opening-request", someData=0x0000000000000000) at nsObserverList.cpp:66 [opt]
    frame #9: 0x00000001100a5b1c XUL`nsObserverService::NotifyObservers(this=<unavailable>, aSubject=0x000000012871f000, aTopic="http-on-opening-request", aSomeData=0x0000000000000000) at nsObserverService.cpp:294 [opt]
    frame #10: 0x0000000110478330 XUL`mozilla::net::nsHttpHandler::NotifyObservers(this=<unavailable>, chan=0x000000012871f000, event="http-on-opening-request") at nsHttpHandler.cpp:835 [opt]
    frame #11: 0x00000001104c209b XUL`mozilla::net::HttpChannelChild::AsyncOpen(nsIStreamListener*) [inlined] mozilla::net::nsHttpHandler::OnOpeningRequest(this=<unavailable>, chan=0x000000012871f000) at nsHttpHandler.h:329 [opt]
    frame #12: 0x00000001104c2085 XUL`mozilla::net::HttpChannelChild::AsyncOpen(this=0x000000012871f000, aListener=<unavailable>) at HttpChannelChild.cpp:2488 [opt]
    frame #13: 0x00000001127001fd XUL`mozilla::dom::XMLHttpRequestMainThread::InitiateFetch(this=0x0000000127b61c00, aUploadStream=<unavailable>, aUploadLength=<unavailable>, aUploadContentType=0x00007ffee4b19598) at XMLHttpRequestMainThread.cpp:2640 [opt]
    frame #14: 0x00000001127011b4 XUL`mozilla::dom::XMLHttpRequestMainThread::SendInternal(this=0x0000000127b61c00, aBody=<unavailable>, aBodyIsDocumentOrString=<unavailable>) at XMLHttpRequestMainThread.cpp:2868 [opt]
    frame #15: 0x00000001127009fb XUL`mozilla::dom::XMLHttpRequestMainThread::Send(this=<unavailable>, aCx=<unavailable>, aData=<unavailable>, aRv=0x00007ffee4b197e8) at BodyExtractor.h:0 [opt]
    frame #16: 0x00000001127062d0 XUL`mozilla::dom::SendRunnable::RunOnMainThread(this=0x000000013d91e640, aRv=0x00007ffee4b197e8) at XMLHttpRequestWorker.cpp:1403 [opt]
    frame #17: 0x0000000112705b85 XUL`mozilla::dom::WorkerThreadProxySyncRunnable::MainThreadRun(this=0x000000013d91e640) at XMLHttpRequestWorker.cpp:1245 [opt]
    frame #18: 0x00000001125d34b3 XUL`mozilla::dom::WorkerMainThreadRunnable::Run(this=0x000000013d91e640) at WorkerRunnable.cpp:569 [opt]
    frame #19: 0x000000011011bb0c XUL`mozilla::ThrottledEventQueue::Inner::ExecuteRunnable(this=<unavailable>) at ThrottledEventQueue.cpp:243 [opt]
    frame #20: 0x0000000110119d3d XUL`mozilla::ThrottledEventQueue::Inner::Executor::Run(this=<unavailable>) at ThrottledEventQueue.cpp:80 [opt]
    frame #21: 0x0000000110110ee1 XUL`nsThread::ProcessNextEvent(this=0x000000010b64eac0, aMayWait=<unavailable>, aResult=0x00007ffee4b19d9f) at nsThread.cpp:1180 [opt]
    frame #22: 0x0000000110113669 XUL`NS_ProcessNextEvent(aThread=<unavailable>, aMayWait=true) at nsThreadUtils.cpp:486 [opt]
    frame #23: 0x000000011065d116 XUL`mozilla::ipc::MessagePump::Run(this=0x000000010b65e6f0, aDelegate=0x00007ffee4b19fb8) at MessagePump.cpp:110 [opt]
    frame #24: 0x000000011061b809 XUL`MessageLoop::Run() [inlined] MessageLoop::RunInternal(this=<unavailable>) at message_loop.cc:315 [opt]
    frame #25: 0x000000011061b7fa XUL`MessageLoop::Run() [inlined] MessageLoop::RunHandler(this=<unavailable>) at message_loop.cc:308 [opt]
    frame #26: 0x000000011061b7fa XUL`MessageLoop::Run(this=<unavailable>) at message_loop.cc:290 [opt]
    frame #27: 0x0000000112822e29 XUL`nsBaseAppShell::Run(this=0x000000010b757700) at nsBaseAppShell.cpp:137 [opt]
    frame #28: 0x000000011288d4cf XUL`nsAppShell::Run(this=0x000000010b757700) at nsAppShell.mm:702 [opt]
    frame #29: 0x0000000113c46cb8 XUL`XRE_RunAppShell() at nsEmbedFunctions.cpp:919 [opt]
    frame #30: 0x000000011061b809 XUL`MessageLoop::Run() [inlined] MessageLoop::RunInternal(this=<unavailable>) at message_loop.cc:315 [opt]
    frame #31: 0x000000011061b7fa XUL`MessageLoop::Run() [inlined] MessageLoop::RunHandler(this=<unavailable>) at message_loop.cc:308 [opt]
    frame #32: 0x000000011061b7fa XUL`MessageLoop::Run(this=<unavailable>) at message_loop.cc:290 [opt]
    frame #33: 0x0000000113c46a5a XUL`XRE_InitChildProcess(aArgc=<unavailable>, aArgv=<unavailable>, aChildData=<unavailable>) at nsEmbedFunctions.cpp:757 [opt]
    frame #34: 0x000000010b0e5f07 plugin-container`main [inlined] content_process_main(bootstrap=0x000000010b60b180, argc=<unavailable>, argv=0x00007ffee4b1a248) at plugin-container.cpp:56 [opt]
    frame #35: 0x000000010b0e5edb plugin-container`main(argc=<unavailable>, argv=0x00007ffee4b1a248) at MozillaRuntimeMain.cpp:23 [opt]
    frame #36: 0x00007fff5a74d085 libdyld.dylib`start + 1
    frame #37: 0x00007fff5a74d085 libdyld.dylib`start + 1
Assignee: nobody → bhackett1024
Flags: needinfo?(bhackett1024)
Attached patch WIP (obsolete) — — Splinter Review

This WIP is able to associate the stack of a 'new Worker("foo.js")' call with the network request for "foo.js" in the network panel. This extends the logic added in bug 1543751 to allow stacks to be saved (in C++) on any thread, passed around to other threads, and finally be decoded on the main thread, converted to JSON, and passed to the network monitor's stack trace collector via the observer service.

This still needs extension to handle XHR requests and script imports made by workers, and I'm hoping to use it to deal with bug 1392411 as well (though I haven't diagnosed that one yet).

The main sticking point here is that it would be nice to only collect these stacks if the network monitor is active for the window associated with a channel. Is there an easy way to determine this in C++?

Attached patch patch — — Splinter Review

Complete patch, handling stacks for worker creation (on the main thread or in workers), worker XHRs, worker importScripts() calls, and WebSocket creation (on the main thread or in workers).

This patch always creates these stacks, even when the net monitor is inactive. I think the cases where these stacks are created are rare enough and/or have enough other costs that the perf impact here should be small, but it would still be nice to fix sometime.

I'll split this up for review tomorrow morning (putting some parts of it in bug 1392411, since this patch fixes both bugs).

Attachment #9059357 - Attachment is obsolete: true
Blocks: 1546736
Blocks: 1547145
Blocks: 1547146
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/872645a5122c
Part 1 - Add interface to help convert SavedFrames to JSON, r=jimb.
https://hg.mozilla.org/integration/mozilla-inbound/rev/01fd757e335b
Part 2 - Encapsulate threadsafe main/worker stacks in WorkerStackHolder, r=bzbarsky.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d88d5959f4a6
Part 3 - Report stacks to net monitor when loading worker scripts, r=bzbarsky.
https://hg.mozilla.org/integration/mozilla-inbound/rev/cd9081aac4bf
Part 4 - Report stacks to net monitor when opening XHRs from worker, r=bzbarsky.
https://hg.mozilla.org/integration/mozilla-inbound/rev/69cbc0afb1f1
Part 5 - Listen for alternate stack traces in StackTraceCollector, r=ochameau.
https://hg.mozilla.org/integration/mozilla-inbound/rev/a32ab60deb60
Part 6 - Add test for capturing worker stacks in net monitor, r=ochameau.
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/337d93c03c2e
Part 1 - Add interface to help convert SavedFrames to JSON, r=jimb.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b765eaf69bcb
Part 2 - Encapsulate threadsafe main/worker stacks in WorkerStackHolder, r=bzbarsky.
https://hg.mozilla.org/integration/mozilla-inbound/rev/2a64ecfab240
Part 3 - Report stacks to net monitor when loading worker scripts, r=bzbarsky.
https://hg.mozilla.org/integration/mozilla-inbound/rev/9c3b9f800a0c
Part 4 - Report stacks to net monitor when opening XHRs from worker, r=bzbarsky.
https://hg.mozilla.org/integration/mozilla-inbound/rev/855b8dd227f9
Part 5 - Listen for alternate stack traces in StackTraceCollector, r=ochameau.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac9c08f90cd0
Part 6 - Add test for capturing worker stacks in net monitor, r=ochameau.
https://hg.mozilla.org/integration/mozilla-inbound/rev/05656abf3e6c
Part 7 - Fix build failures due to the interaction of a new source file with the unified source build system.

Backed out 7 changesets (Bug 1392408) for mochitest failures at test_xhr_withCredentials.html and xpcshell failures at test_startup_(no)session_async.js

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=pending%2Crunning%2Ctestfailed%2Cbusted%2Cexception&revision=05656abf3e6c6862ba89990fd9ba3854fe5eb5f1&selectedJob=244396721

Failure log:

  1. Mochitest failure: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=244413587&repo=mozilla-inbound&lineNumber=1895
  2. Xpcshell failure: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=244396669&repo=mozilla-inbound&lineNumber=9327

Backout link: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=244400141&revision=9dbf4a541fff28274537c379f29b7bdb58cfd60d

03:52:00     INFO -  TEST-START | browser/components/sessionstore/test/unit/test_startup_session_async.js
03:57:00  WARNING -  TEST-UNEXPECTED-TIMEOUT | browser/components/sessionstore/test/unit/test_startup_session_async.js | Test timed out
03:57:00     INFO -  TEST-INFO took 300000ms
03:57:00     INFO -  >>>>>>>
03:57:00     INFO -  PID 10536 | Unable to load \\untrusted-startup-test-dll.dll; LoadLibraryW failed: 126[10536, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, NS_ERROR_UNEXPECTED) failed with result 0x80004005: file z:/build/build/src/extensions/permissions/nsPermissionManager.cpp, line 1026
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: Couldn't get the user appdata directory. Crash events may not be produced.: file z:/build/build/src/toolkit/crashreporter/nsExceptionHandler.cpp, line 2528
03:57:00     INFO -  (xpcshell/head.js) | test MAIN run_test pending (1)
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, kKnownEsrVersion) failed with result 0x80004002: file z:/build/build/src/toolkit/components/resistfingerprinting/nsRFPService.cpp, line 662
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file z:/build/build/src/extensions/permissions/nsPermissionManager.cpp, line 2910
03:57:00     INFO -  (xpcshell/head.js) | test pending (2)
03:57:00     INFO -  (xpcshell/head.js) | test MAIN run_test finished (2)
03:57:00     INFO -  running event loop
03:57:00     INFO -  "Waiting for session startup initialization"
03:57:00     INFO -  "Session startup initialization observed"
03:57:00     INFO -  TEST-PASS | browser/components/sessionstore/test/unit/test_startup_session_async.js | cb - [cb : 25] 3 == 3
03:57:00     INFO -  (xpcshell/head.js) | test finished (1)
03:57:00     INFO -  exiting test
03:57:00     INFO -  PID 10536 | JavaScript strict warning: resource:///modules/sessionstore/SessionFile.jsm, line 143: ReferenceError: reference to undefined property "platformBuildID"
03:57:00     INFO -  "CONSOLE_MESSAGE: (warn) [JavaScript Warning: "ReferenceError: reference to undefined property "platformBuildID"" {file: "resource:///modules/sessionstore/SessionFile.jsm" line: 143}]"
03:57:00     INFO -  PID 10536 | [10536, Main Thread] WARNING: Failed to get base domain!: file z:/build/build/src/ipc/glue/BackgroundUtils.cpp, line 321
03:57:00     INFO -  PID 10536 | ###!!! [Parent][DispatchAsyncMessage] Error: PClientSource::Msg_Teardown Route error: message sent to unknown actor ID
03:57:00     INFO -  PID 10536 | ###!!! [Parent][DispatchAsyncMessage] Error: PClientManager::Msg_Teardown Route error: message sent to unknown actor ID
03:57:00     INFO -  PID 10536 | [10536, DOM Worker] WARNING: 'aRv.Failed()', file z:/build/build/src/dom/xhr/XMLHttpRequestWorker.cpp, line 219
03:57:00     INFO -  PID 10536 | [10536, DOM Worker] WARNING: '!holder->HoldWorker(aWorkerPrivate, aFailStatus)', file z:/build/build/src/dom/workers/WorkerRef.cpp, line 176
03:57:00     INFO -  <<<<<<<
03:57:00     INFO -  xpcshell return code: 1

Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7494e80f5b3e
Part 1 - Add interface to help convert SavedFrames to JSON, r=jimb.
https://hg.mozilla.org/integration/mozilla-inbound/rev/7cebca65fa31
Part 2 - Encapsulate threadsafe main/worker stacks in WorkerStackHolder, r=bzbarsky.
https://hg.mozilla.org/integration/mozilla-inbound/rev/fdff2d33f119
Part 3 - Report stacks to net monitor when loading worker scripts, r=bzbarsky.
Flags: needinfo?(bhackett1024)
Whiteboard: leave-open

The treeherder failures are pretty strange and it's not clear what's going on, so I'm going to try landing things piecemeal to figure out what's happening. Fixing bug 1546736 before the rest of this lands might help too.

Status: NEW → ASSIGNED
Whiteboard: leave-open → [debugger-mvp] leave-open

The remaining treeherder failure is fixed by the changes in bug 1546736 to avoid capturing stacks unless the devtools are watching the associated docshell. So, the rest of this bug will need to land in concert with that bug.

No longer blocks: 1546736
Depends on: 1546736

Do we also need a followup for handling fetch() in workers?

Flags: needinfo?(bhackett1024)

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #23)

Do we also need a followup for handling fetch() in workers?

Yeah, we do. I just filed bug 1551256.

Flags: needinfo?(bhackett1024)
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/181465d74bc4
Part 4 - Report stacks to net monitor when opening XHRs from worker, r=bzbarsky.
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8a7327b91ed2
Part 5 - Listen for alternate stack traces in StackTraceCollector, r=ochameau.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5168e91ed5b4
Part 6 - Add test for capturing worker stacks in net monitor, r=ochameau.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: