You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lit lines that try to run a program that does not exist will cause the execution of lit to hang. This only occurs with tests inside the sycl/test-e2e and sycl/test folders, and only when using one of our containers.
To reproduce
Include a code snippet that is as short as possible
Add the following file to either sycl/test-e2e or sycl/test
// RUN: non_existent
Specify the command which should be used to compile the program
Specify the command which should be used to launch the program llvm-lit ./test.cpp
Indicate what is wrong and what was expected
The test itself should fail immediately, but lit will not immediately report the test statistics and quit. Instead it will hang until either you send an interrupt signal, or a timeout of 10mins is reached.
This seemingly happens if inside one of the processes a function raises an exception and it is not caught by the function who directly calls the throwing function. In our case this occurs in the _executeShCmd function
adding a try/except to the executeShCmd circumvents this hang.
However it is unclear if this is actually an issue in upstream llvm, since this is not reproducible in either the clang/test or llvm/test folders (To be able to compare we need to set useExternalSh to false in the call of lit.TestRunner._runShTest), and this is only reproducible in our containers.
Setting useExternalSh to true in the call of lit.TestRunner._runShTest also works as a workaround which is what is done in #16321 to avoid the hang. However this makes the test stdout less readable (all stdout is printed in one block, rather than separated by RUN: lines).
The text was updated successfully, but these errors were encountered:
Describe the bug
Lit lines that try to run a program that does not exist will cause the execution of lit to hang. This only occurs with tests inside the
sycl/test-e2e
andsycl/test
folders, and only when using one of our containers.To reproduce
Add the following file to either
sycl/test-e2e
orsycl/test
// RUN: non_existent
llvm-lit ./test.cpp
The test itself should fail immediately, but lit will not immediately report the test statistics and quit. Instead it will hang until either you send an interrupt signal, or a timeout of 10mins is reached.
Environment
ubuntu2204_intel_drivers:alldeps
(confirmed locally)ubuntu2204_intel_drivers:latest
(observed on ci)NOTE: Doesn't reproduce outside of a container, or in some other containers.
Additional context
The hang occurs at the call to the
multiprocessing.Pool.join
method inside the lit implementation.llvm/llvm/utils/lit/lit/run.py
Lines 87 to 93 in 3565b58
This seemingly happens if inside one of the processes a function raises an exception and it is not caught by the function who directly calls the throwing function. In our case this occurs in the
_executeShCmd
functionllvm/llvm/utils/lit/lit/TestRunner.py
Lines 860 to 861 in 3565b58
The
executeShCmd
function calls_executeShCmd
, however it does not catch this exception, rather this is caught inexecuteScriptInternal
llvm/llvm/utils/lit/lit/TestRunner.py
Lines 1108 to 1116 in 3565b58
adding a try/except to the
executeShCmd
circumvents this hang.However it is unclear if this is actually an issue in upstream llvm, since this is not reproducible in either the
clang/test
orllvm/test
folders (To be able to compare we need to setuseExternalSh
to false in the call oflit.TestRunner._runShTest
), and this is only reproducible in our containers.Probably related: https://stackoverflow.com/questions/15314189/python-multiprocessing-pool-hangs-at-join
Setting
useExternalSh
to true in the call oflit.TestRunner._runShTest
also works as a workaround which is what is done in #16321 to avoid the hang. However this makes the test stdout less readable (all stdout is printed in one block, rather than separated byRUN:
lines).The text was updated successfully, but these errors were encountered: