Irregular `Tested application kept running even after SIGABRT` test suite failures about turtle HOT 7 CLOSED

Closing for now, please reopen if issue still manifests with increased wait time

from turtle.

What happens if you send SIGABRT to your app manually (kill -6 <pid>)?

from turtle.

First attempts, it always seems to just abort immediately. But this is a very basic case where the app is not actually "busy" (I didn't set up a DHT for it to work with).

from turtle.

I've also tried issuing a SIGABRT to the tested app mid-integration-test-run, and again, it seems to shut down immediately.

BTW, the test suite has some special-casing to handle the fact that the app may wait up to 5 seconds for a task to complete. I tried removing this, and it doesn't seem to create any problems for the app to shut down.

That said, I don't think I've ever seen this failure in a local test run, only in CI.

from turtle.

I do wonder if the D2 runtime is blocking the signal dispatch while in GC cycle or something similar, where the application will not be able to react to SIGABRT.

from turtle.

Here's one such place where the all signals except the resume signal are masked:

https://github.com/dlang/druntime/blob/86cd40a036a67d9b1bff6c14e91cba1e5557b119/src/core/thread.d#L446-L456

from turtle.

Current guess is that because of that GC intervention default turtle wait time of 0.1 seconds is not enough. New #48 PR allows to configure final wait time from the test suite to be able to confirm this suspicion.

from turtle.