demarey
commented
4 years ago core problem is https://github.com/pharo-contributions/OSSubprocess/issues/58. Now check if image can be launched before launching to avoid to listen to stderr. See a8b29c04b2031b98fc6ceb8735c395833250fb7a
Describe the bug Reported by @Ducasse and @guillep: Launched image get unresponsive after some time. It looks like it happens with a self halt in the code and using the debugger.
To Reproduce Run tests Then I did
$ kill -SIGUSR1 pidSomehow, that unblocked my image, but still produced a debug.log and a crash.dmp And then, when doing the signal, not only the image unblocks, but the launcher shows this:So this means that the launcher is still attached to the process, but probably it’s not consuming the output in the standard streams (which makes our image lock up on write because the pipe’s buffer may be full?)
Expected behaviour Responsive image :)
Additional context It seems the process blocks when writing (an exception stack trace) to stdout
This is probably related to the fact that the launcher is now trying to listen to the stdout output to see if there is an error launching the process. @tesonep suggested: The PharoLauncher is taking the output of the launched stdout/stderr in a pipe. And as a Pipe has a limit, if the PharoLauncher is not removing elements from the pipe or it is done slowly, the producing process (the launched VM) will block until there is space in the pipe.