
Key: |
QB-2624
|
Type: |
Bug
|
Status: |
Closed
|
Resolution: |
Cannot Reproduce
|
Priority: |
Major
|
Assignee: |
Robin Shen
|
Reporter: |
mm
|
Votes: |
0
|
Watchers: |
0
|
If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 13/Jan/16 07:38 AM
Updated: 01/Dec/16 09:12 AM
|
|
Component/s: |
None
|
Affects Version/s: |
None
|
Fix Version/s: |
None
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
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.
|
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.
|
Show » |
No work has yet been logged on this issue.
|
|