I’ve been running some fairly long site lists through a modified WPT 2.12 lately and noticing that after running for a while the driver gets stuck at “Waiting X seconds for site to complete” and hangs there forever. I’ve been trying to debug what could be causing this but I’ve had no luck, it finishes SetSite() and then just nothing, even though it should be continuing to load more.
I’ve attached a log of the test running, we have modified the order of how sites are run in a list, but have not touched any of the code relating to how a site is loaded (to my knowledge) so I assume this is an issue with the unmodified version of the drivers as well. Any help with this, either pointing me in the direction of where the issue could be, or a patch would be appreciated.
The trace looks like it got to the point where IE closed but maybe IE didn’t go away completely. The IE code was REALLY buggy in 2.12 and was one of the major fixes in 2.13 which just rolled out last night - I’d recommend grabbing an updated agent to see if it does any better.
It’s a little strange as well because wptdriver should timeout waiting for the browser to complete gracefully and should force-terminate it after the timeout.
Looking through the code it looks like when in Debug mode, it removes the timeout, in web_browser.cc:
#ifdef DEBUG
if (WaitForSingleObject(_browser_process, INFINITE ) ==
WAIT_OBJECT_0 ) {
ret = true;
}
So I am guessing that is why it never force-terminates. I tried again using the drivers built for Release and it indeed does not hang anymore… but instead once it tries to force IE closed it causes the machine to BSOD and crash.
I noticed your rollout of 2.13 this morning and grabbed that code… I’ve been running it and haven’t seen a hang/BSOD yet so I think you may have gotten whatever was causing the issue, though I’ll report back if I see it again.
Is the infinite wait intended when the drivers are built in Debug mode? It is nice to be able to pull a full trace, but the browser not being able to timeout is a bit of an issue…
Yes, the infinite wait is intended because if you’re actually debugging it (like with a debugger attached, stepping through code) it really sucks to have it yanked out from under you
You can run a release build of wptdriver with a debug hook and bho which would give you the traces for just about everything.
So new issue with the 2.13 drivers and IE. I am noticing that in the waterfalls I am seeing quite a few places where an HTTPS request finishes SSL negotiation and then there is a delay of almost 20 seconds before it makes the actual request. Have you ever seen this before?
We are seeing this same issue on our WPT private instance. Saw it on 2.12 and are still seeing it after upgrading to 2.13. Would also like to know the answer to this one and a fix(if any).