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)
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)