Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SandboxModule#afterCommand swallows interrupts #1084

Closed
haxorz opened this issue Mar 24, 2016 · 1 comment
Closed

SandboxModule#afterCommand swallows interrupts #1084

haxorz opened this issue Mar 24, 2016 · 1 comment
Assignees
Labels
category: sandboxing P2 We'll consider working on this in future. (Assignee optional) type: bug

Comments

@haxorz
Copy link
Contributor

haxorz commented Mar 24, 2016

SandboxModule#afterCommand swallows interrupts and blocks. so if you get unlucky, bazel can hang after you interrupt it during e.g. a long-running sandboxed local test. example thread stack after i interrupted bazel:

"main" #1 prio=5 os_prio=0 tid=0x00007f9c08035000 nid=0x2810 waiting on condition [0x00007f9c10075000]
java.lang.Thread.State: TIMED_WAITING (parking)
at (C/C++) __pthread_cond_timedwait( (/usr/grte/v4/lib64/libpthread.so.0))
at (C/C++) Unsafe_Park( (/usr/local/buildtools/java/jdk8-google-v7-64/jre/lib/amd64/server/libjvm.so))
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000005cc6097d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
at com.google.devtools.build.lib.concurrent.ExecutorUtil.shutdownImpl(ExecutorUtil.java:64)
at com.google.devtools.build.lib.concurrent.ExecutorUtil.interruptibleShutdown(ExecutorUtil.java:41)
at com.google.devtools.build.lib.sandbox.SandboxModule.afterCommand(SandboxModule.java:109)
at com.google.devtools.build.lib.runtime.BlazeRuntime.afterCommand(BlazeRuntime.java:659)
at com.google.devtools.build.lib.runtime.BlazeCommandDispatcher.exec(BlazeCommandDispatcher.java:389)
at com.google.devtools.build.lib.runtime.BlazeRuntime$3.exec(BlazeRuntime.java:1044)
at com.google.devtools.build.lib.server.RPCService.executeRequest(RPCService.java:65)
at com.google.devtools.build.lib.server.RPCServer.executeRequest(RPCServer.java:454)
at com.google.devtools.build.lib.server.RPCServer.serve(RPCServer.java:233)
at com.google.devtools.build.lib.runtime.BlazeRuntime.serverMain(BlazeRuntime.java:999)
at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:796)
at com.google.devtools.build.lib.bazel.BazelMain.main(BazelMain.java:56)

@aehlig aehlig added type: bug P2 We'll consider working on this in future. (Assignee optional) labels Mar 30, 2016
@philwo
Copy link
Member

philwo commented Oct 13, 2016

Fixed in 95b16a8

@philwo philwo closed this as completed Oct 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: sandboxing P2 We'll consider working on this in future. (Assignee optional) type: bug
Projects
None yet
Development

No branches or pull requests

4 participants