Debugging Task Scheduling (on Mac)

[Adam Parker]

I'm trying to figure out why some tasks that are getting posted to the UI thread aren't getting executed (this is on Mac, other platforms are working fine).  Are there any suggestions for how to debug what happens to a task after it has been added to the queue?

More specifically (if anyone is interested), I've tracked the task posted here: 

https://cs.chromium.org/chromium/src/content/browser/media/capture/web_contents_video_capture_device.cc?l=213

all the way into the incoming task queue, but I never see it executed and I'm stuck on figuring out why.

Thanks,

-Adam

[Gabriel Charette]

Try to add logging to MessageLoop::DoWork() @

bool MessageLoop::DoWork() {

  if (!task_execution_allowed_) {

    LOG(WARNING) << "Entering nested scope: " << debug::StackTrace().ToString();

    return false;

  }

  (...)

I suspect the Mac MessagePump is entering a nested loop and intentionally not processing application tasks (to avoid unintended reentrancy). Note: you can explicitly allow this when safe in a given scope with a MessageLoop::ScopedNestableTaskAllower.

Cheers,

Gab

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH%3DjVrbTafOshUHJTXZ_-y1YrteMjbWkx--5F-Qj1-8MkMYv8Q%40mail.gmail.com.

[Adam Parker]

Thanks for the suggestions about nested loops, it got me looking into different parts of the system. Apparently on Mac, parts of the capture pipeline are run on the main thread (despite many comments specifying things running on device threads). This seems to be what causes the issue, where things are being deleted before the tasks that reference them can run.

What I'm not clear on is why it works on other platforms when there are separate threads.  Is there logic somewhere that keeps an object from deleting itself if it has posted a task to a separate thread?  Otherwise it feels like the other platforms are just a race condition that happens to work right now.

[Wez]

Regarding the tash not getting run:

The task posted at the link that you provided is explicitly bound to a WeakPtr to the |tracker_| - are you sure that the |tracker_| isn't getting deleted before the UI thread gets around to processing that task (i.e. things working-as-intended with regard to coping with asynchronous teardown).

Regarding this code's threading:

The code is PostTask()ing to the |tracker_| via a reference from AsWeakPtr(). The posting class actually owns |tracker_|, though, and holds it in a DeleteOnUiThread containing. This means the code is either doing unnecessary work, or is racy/broken:

- If we only ever post these tasks from the same thread on which the calling code is torn-down then all the posted tasks are well-serialized, so we don't even need to use WeakPtrs - we are already guaranteed that the work posting tasks will be processed in-order with the |tracker_| deletion task.

- If we post these tasks from some other capture threads then we cannot rely on this ordering, and in that case we should also not be relying on |tracker_| still being valid even at the time of the PostTask() call, let alone when the task is actually being processed.

There may be some surrounding ordering constraints arising from specifics of the calling code that make this safe, but at a glance something does look amiss.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAH%3DjVrYAQ4bQ%2BtHqn5RSWBddOUGC6v3eQ%3DHUBtvhY0Cerjm%2B4Q%40mail.gmail.com.