-
Notifications
You must be signed in to change notification settings - Fork 119
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
Execution hangs when exceptions are thrown #649
Comments
@RainNapper Thanks for reporting this bug, have you encountered similar issue with other cases? |
Brought up some more details in slack message here: https://firebase-community.slack.com/archives/C72V6UW8M/p1583276521008200 Copy pasting here: I filed #649 But I think I narrowed it down to couple things:
If you're curious, here's the first couple lines of the
|
Hello, @bootstraponline raised a ticket on the picocli issue tracker and asked me to help with investigation on this issue, mentioning that "It seems like the root cause is due to picocli". I'm not convinced yet that this is the case, but I'm happy to help. First, @RainNapper's point (1):
Does Flank or The non-daemon thread hypothesis may also explain @RainNapper's point (2):
It is true that picocli only catches Exceptions and not Errors. But this does not mean that the Putting those together, perhaps the // Main.kt
companion object {
@JvmStatic
fun main(args: Array<String>) {
try {
exitProcess(CommandLine(Main()).execute(*args))
} (catch t: Throwable) {
t.printStackTrace()
exitProcess(picocli.CommandLine.ExitCode.SOFTWARE)
}
}
} |
That looks good to me. The only thing I did before concluding that What you said sounds like a good explanation to me, and thus the changes look good too. Thanks for the input! Very much appreciated. |
@remkop Thank you for the insight! That makes sense. |
Glad I was able to help. Remember: your picocli GitHub 🌠 stars are the only thing that fill the yawning void in my soul! 😉 |
Additionally, assuming that my hypothesis holds water and the problem is caused by non-daemon threads preventing the JVM from exiting, if Flank creates those threads, Flank could also consider making those threads daemon threads. (I would still recommend the above changes in case something else creates a non-daemon thread.) |
Hey, I managed to find root cause of this issue. While debugging I noticed that flank has non-daemon thread (as @remkop predicted). Digging deeper lead me to this line in
Bugsnag uses its own thread pool to handle sending statistics, reports etc. This executor is not closed properly and in this case prevents jvm from shutting down. I verified this by closing bugsnag manually by simple call
and in all cases flank terminated successfully. When I tracked down it is bugsnag I found there is already issue posted Bugsnag#151 I tried proposed solution but I think simple wrapping with |
@pawelpasterz Thanks for figuring this out! |
@pawelpasterz The proposed solution covers against the case where some component in the call stack starts a non-daemon thread, and then throws an I'm not sure if any of the components you are currently testing against show this behaviour (I assumed they did, since @RainNapper brought it up). Even if there are currently no such components, it may still be worth protecting against them. :-) |
@remkop got your point, I'll change my fix then. Thanks for pointing this out |
When passing in a test filter that is improperly formed, Flank will throw an exception but will not terminate. When flank is run in CI, this causes unnecessary timeouts while the scripts are waiting for the command to finish.
Example error
java.lang.IllegalArgumentException: Invalid argument: com.package.Class#testMethod at ftl.filter.TestFilters.parseSingleFilter(TestFilters.kt:100) at ftl.filter.TestFilters.access$parseSingleFilter(TestFilters.kt:31) at ftl.filter.TestFilters$fromTestTargets$parsedFilters$2.invoke(TestFilters.kt:85) at ftl.filter.TestFilters$fromTestTargets$parsedFilters$2.invoke(TestFilters.kt:31) at kotlin.sequences.TransformingSequence$iterator$1.next(Sequences.kt:172) at kotlin.sequences.SequencesKt___SequencesKt.toCollection(_Sequences.kt:702) at kotlin.sequences.SequencesKt___SequencesKt.toMutableList(_Sequences.kt:732) at kotlin.sequences.SequencesKt___SequencesKt.toList(_Sequences.kt:723) at ftl.filter.TestFilters.fromTestTargets(TestFilters.kt:86) at ftl.args.AndroidTestShard.getTestMethods(AndroidTestShard.kt:32) at ftl.args.AndroidTestShard.getTestShardChunks(AndroidTestShard.kt:25) at ftl.run.AndroidTestRunner$runTests$2.invokeSuspend(AndroidTestRunner.kt:38) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.ResumeModeKt.resumeUninterceptedMode(ResumeMode.kt:45) at kotlinx.coroutines.internal.ScopeCoroutine.afterCompletionInternal(Scopes.kt:32) at kotlinx.coroutines.JobSupport.completeStateFinalization(JobSupport.kt:311) at kotlinx.coroutines.JobSupport.tryFinalizeFinishingState(JobSupport.kt:237) at kotlinx.coroutines.JobSupport.tryMakeCompletingSlowPath(JobSupport.kt:851) at kotlinx.coroutines.JobSupport.tryMakeCompleting(JobSupport.kt:813) at kotlinx.coroutines.JobSupport.makeCompletingOnce$kotlinx_coroutines_core(JobSupport.kt:789) at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:111) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46) at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241) at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.kt:116) at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:79) at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:54) at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source) at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:36) at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source) at ftl.cli.firebase.test.android.AndroidRunCommand.run(AndroidRunCommand.kt:49) at picocli.CommandLine.executeUserObject(CommandLine.java:1687) at picocli.CommandLine.access$900(CommandLine.java:146) at picocli.CommandLine$RunLast.handle(CommandLine.java:2059) at picocli.CommandLine$RunLast.handle(CommandLine.java:2026) at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:1893) at picocli.CommandLine.execute(CommandLine.java:1822) at ftl.Main$Companion.main(Main.kt:41) at ftl.Main.main(Main.kt)
The text was updated successfully, but these errors were encountered: