Summary: | new-run-webkit-tests: Every few runs, Windows Tests hang indefinitely somewhere in Python guts | ||
---|---|---|---|
Product: | WebKit | Reporter: | Dimitri Glazkov (Google) <dglazkov> |
Component: | Tools / Tests | Assignee: | Dirk Pranke <dpranke> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | dpranke, eric, evan, tkent, victorw |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | Windows Vista | ||
Bug Depends on: | 49566 | ||
Bug Blocks: | 34984, 38023 |
Description
Dimitri Glazkov (Google)
2010-08-05 10:49:54 PDT
_dump_thread_states_if_necessary bits are just the code that is dumping the current state of the world for debugging purposes, right? So it's hanging in the subprocess stdout read. That probably indicates stdout buffering. What is the subprocess? If it's C code, see "man 3 setvbuf" (set it to line buffering). If it's Python code, do something like sys.stdout = os.fdopen(1, 'w', 1) # last arg of 1 means line buffering This is almost certainly the same issue as bug 36622 and bug 38200 (which aren't actually mac specific, and the cause is believed to be well-understood). Assigning to me. Evan's right that the problem is caused by subprocess, but it's not so much stdout buffering as it is the fact that we're using PIPEs with a fixed buffer size (even on windows), and overflowing the buffer causes the threads to deadlock. (In reply to comment #2) > This is almost certainly the same issue as bug 36622 and bug 38200 (which aren't actually > mac specific, and the cause is believed to be well-understood). Assigning to me. > > Evan's right that the problem is caused by subprocess, but it's not so much stdout buffering as it is the fact that we're using PIPEs with a fixed buffer size (even on windows), and overflowing the > buffer causes the threads to deadlock. Thanks Dirk! Another thing of note: when I go kill processes to clean up this mess, I also see ruby.exe running. (In reply to comment #3) > (In reply to comment #2) > > This is almost certainly the same issue as bug 36622 and bug 38200 (which aren't actually > > mac specific, and the cause is believed to be well-understood). Assigning to me. > > > > Evan's right that the problem is caused by subprocess, but it's not so much stdout buffering as it is the fact that we're using PIPEs with a fixed buffer size (even on windows), and overflowing the > > buffer causes the threads to deadlock. > > Thanks Dirk! Another thing of note: when I go kill processes to clean up this mess, I also see ruby.exe running. Yeah, the ruby.exe comes from the pretty diff ; it is definitely one of the culprits. (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > This is almost certainly the same issue as bug 36622 and bug 38200 (which aren't actually > > > mac specific, and the cause is believed to be well-understood). Assigning to me. > > > > > > Evan's right that the problem is caused by subprocess, but it's not so much stdout buffering as it is the fact that we're using PIPEs with a fixed buffer size (even on windows), and overflowing the > > > buffer causes the threads to deadlock. > > > > Thanks Dirk! Another thing of note: when I go kill processes to clean up this mess, I also see ruby.exe running. > > Yeah, the ruby.exe comes from the pretty diff ; it is definitely one of the culprits. Cool. This time when it hang, it was wdiff.exe. (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > This is almost certainly the same issue as bug 36622 and bug 38200 (which aren't actually > > > > mac specific, and the cause is believed to be well-understood). Assigning to me. > > > > > > > > Evan's right that the problem is caused by subprocess, but it's not so much stdout buffering as it is the fact that we're using PIPEs with a fixed buffer size (even on windows), and overflowing the > > > > buffer causes the threads to deadlock. > > > > > > Thanks Dirk! Another thing of note: when I go kill processes to clean up this mess, I also see ruby.exe running. > > > > Yeah, the ruby.exe comes from the pretty diff ; it is definitely one of the culprits. > > Cool. This time when it hang, it was wdiff.exe. BTW, killing just ruby.exe seemed to have unwedged the script. (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > (In reply to comment #2) > > > > > This is almost certainly the same issue as bug 36622 and bug 38200 (which aren't actually > > > > > mac specific, and the cause is believed to be well-understood). Assigning to me. > > > > > > > > > > Evan's right that the problem is caused by subprocess, but it's not so much stdout buffering as it is the fact that we're using PIPEs with a fixed buffer size (even on windows), and overflowing the > > > > > buffer causes the threads to deadlock. > > > > > > > > Thanks Dirk! Another thing of note: when I go kill processes to clean up this mess, I also see ruby.exe running. > > > > > > Yeah, the ruby.exe comes from the pretty diff ; it is definitely one of the culprits. > > > > Cool. This time when it hang, it was wdiff.exe. > > BTW, killing just ruby.exe seemed to have unwedged the script. Also, installing non-cygwin ruby helped a lot. It hasn't hung in the last 12 runs. I'm closing this ... I assume this has been fixed since we run DRT by default these days. |