| << Back to previous view |
|
[QB-2624] Process End Issue
|
|
| Status: | Closed |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | mm | Assigned To: | Robin Shen |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Description |
|
Looking @ source code files com.pmease.quickbuild.execution.CommandLine and com.pmease.quickbuild.execution.ProcessStreamPumper, we found an issue.
The problem: Quickbuild uses ProcesBuilder to create a new process and gives the new process its own file descriptors for std out/error. Some test code is then spawning processes internally that (likely) reuse these same file descriptors for pushing their own std out/error. The test code is not well written and does not clean up its spawned processes (killing them) when the test code exits. Quickbuild detects the process exit but waits for the file descriptors it set aside for the spawn process to close. Since the test code did not clean up its spawn processes, the streams never close. Quickbuild then enters this /**/marked/**/ loop: InterruptedException interruptedException = null; try { result.setReturnCode(process.waitFor()); } catch (InterruptedException e) { interruptedException = e; Context.getLogger().info("Terminating launched command gracefully..."); terminateProcessTree(process, session, false); } long lastTime = System.currentTimeMillis(); /**/while (!streamPumper.closed()) { try { Thread.sleep(100); } catch (InterruptedException e) { if (System.currentTimeMillis() - lastTime > 5000) { Context.getLogger().info("Unable to terminate launched command gracefully, terminating forcibly instead..."); terminateProcessTree(process, session, true); lastTime = System.currentTimeMillis(); } } }/**/ Quickbuild tries to terminate the rogue processes (which is good), but given the shortcomings of determining sub-processes in Windows (it's an OS thing, not a Quickbuild code thing as we know), it fails to completely terminate all the sub-processes in the sub-process tree and the streams remain unclosed. The loop becomes infinite, catching interrupt exceptions (triggered when you try to cancel the test job manually, or the configuration tries to cancel the job automatically at the end of its step time out period). What is even worse is that when the build timeout is reached, the resource still does not free up! I do believe this is a bug, and at the very least Quickbuild should just close the file descriptors, warn you, and move on. |
| Comments |
| Comment by Robin Shen [ 14/Jan/16 12:55 AM ] |
| The statement "terminateProcessTree(process, session, true)" should kill all processes including child processes spawned by your test code to cause all relevant streams to be closed finally. Are you observing that QB is hanging on this point even if this statement has been called? (Find the log entry: "Unable to terminate launched command gracefully, terminating forcibly instead.") |