<div class="gmail_quote">On Sun, Nov 14, 2010 at 02:48, David Bolen <span dir="ltr"><<a href="http://db3l.net">db3l.net</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> writes:<br>
<br>
> Do we have any idea why the workaround to avoid the popup windows<br>
> stopped working? (assuming it ever worked reliably - I thought it did,<br>
> but that impression may have been incorrect)<br>
<br>
</div>Oh, the pop-up handling for the RTL dialogs still seems to be working<br>
fine (at least I haven't seen any since I put it in place). That, plus<br>
the original buildbot tweaks to block any OS popups still looks solid<br>
for avoiding any dialogs that block a test process.<br>
<br>
This is a completely separate issue, though probably around just as<br>
long, and like the popup problem its frequency changes over time. By<br>
"hung" here I'm referring to cases where something must go wrong with<br>
a test and/or its cleanup such that a python_d process remains<br>
running, usually several of them at the same time. So I end up with a<br>
bunch of python_d processes in the background (but not with any<br>
dialogs pending), which eventually cause errors during attempts the<br>
next time the same builder is used since the file remains in use.<br>
<br>
I expect some of this may be the lack of a good process group cleanup<br>
under Windows, though the root cause may not be unique to Windows. I<br>
see something very similar reasonable frequency on my OSX Tiger<br>
buildbot as well. But since the filesystem there can let the build<br>
tree get cleaned and rebuilt even with a stranded executable, the<br>
impact is minimal on subsequent tests than on Windows, though the OSX<br>
processes do burn a ton of CPU. I run a script on OSX to kill them<br>
off, but that was quick to whip up since in those cases the stranded<br>
processes all end up getting owned by init so it's a simple ps grep<br>
and kill. In the Windows case I'll probably just set a time limit so<br>
if the processes have been around more than a few hours I figure<br>
they're safe to kill.<br>
<font color="#888888"><br>
-- David</font></blockquote><div><br></div><div>Is the dialog closer script available somewhere? I'm guessing this is the same script that closes the window which pops up during test_capi's crash?</div><div><br>I just setup a Windows Server 2008 R2 x64 build slave and noticed it hanging due to the popup.</div>
</div>