Undebuggable workers?

[Eric Uhrhane]

I'm accustomed to debugging workers by putting a breakpoint in WorkerProcessHost::OnProcessLaunched, then attaching to the worker process once I hit it.

Today I'm finding that whenever I do this, the worker script just doesn't start up.  There's no error...it just never responds.  Resource tracking indicates that the script gets read, but it never seems to launch.

If I disable the breakpoint, the worker script runs just fine [up until it hits the error I want to debug].

Is there some sort of a timer that's checking to see that the script starts up within a certain delay, that my breakpoint is messing up?  Was there a recent change to worker startup?

This is on Vista64 on Visual Studio 2005, in case it matters.

Thanks,

     Eric

[Drew Wilson]

I'm not aware of any changes in this area. Dmitry?

-atw

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Dmitry Titov]

I usually use the command-line switches that start worker process in a debugger automatically. Something like this:

For ui_test harness:

out/Debug/ui_tests --gtest_filter="WorkerTest.FLAKY_WorkerClonePort" --extra-chrome-flags="--debug-children=worker --browser-subprocess-path=/usr/local/google/chrome/src/out/Debug/chrome"

(the second flag is needed on Linux so the browser starts the gdb properly)

That automagically prepends "gdb --args" to the starting command line for the worker process.

Dmitry

[Drew Wilson]

It is disturbing that putting a breakpoint at WPH::OnProcessLaunched() causes the worker script to not run. Eric, do you know if the worker process itself goes away?

-atw

[Dmitry Titov]

AFAIK there is no timers on the worker level specifically. Workers may start years after created (for example, because they are stuffed into a queue waiting for a worker process limit to be cleared up). Do you get worker process started up, and can you get any breakpoints in the worker process to be hit?

[Eric Uhrhane]

The process starts up [I can attach to it with Visual Studio], but I never hit any breakpoints in it, and it never starts running the script passed to the worker. If I then break all in the debugger, I get a message that says  "The process appears to be deadlocked (or is not running any user-mode code).  All threads have been stopped.".  After I clear that dialog, the worker process is gone.

Incidentally, this afternoon I can debug a worker the *first* time I run one.  If I hit reload, I get the failure, and if I stop and restart the executable, it works for one run again.

[Dmitry Titov]

That "one time" may sound like something not initialized? Please let us know if you find the culprit!

[Drew Wilson]

It'd be interesting to see if WorkerThread::OnChannelError() is getting invoked for some reason - that's the only thing that should cause the worker process to shutdown AFAICT.

-atw

[Eric Uhrhane]

Nope; no call that I can detect.