CDT's spawner can hang when launching bash in interactive mode

[jonahgraham]

The following started as a bug on embed cdt here: eclipse-embed-cdt/eclipse-plugins#626

When launching bash in interactive mode to run a command, on Ubuntu 24.04 and if Eclipse was launched from a terminal, the bash process hangs.

Consider this code:

import static org.junit.jupiter.api.Assertions.assertEquals;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.List;

import org.eclipse.cdt.utils.spawner.ProcessFactory;
import org.junit.jupiter.api.Test;

public class ProcessFactoryTest {

	@Test
	public void testInteractiveShell() throws IOException {
		String[] cmd = { "/bin/bash", "-i", "-c", "/bin/echo echome" };

		Process process = ProcessFactory.getFactory().exec(cmd, null);

		var reader = new BufferedReader(new InputStreamReader(process.getInputStream()));

		String line;
		List<String> outputLines = new ArrayList<>();
		while ((line = reader.readLine()) != null) {
			outputLines.add(line);
		}

		assertEquals(List.of("echome"), outputLines);

	}

}

If you run this test from an Eclipse started from a terminal, the readLine hangs because the process hangs. If you start Eclipse from the launcher (or file manager) the readLine succeeds.

If you remove the -i then bash starts fine and the test passes.

I have spent some time trying to understand what is different about Eclipse/Linux/anything between when Eclipse starts in the terminal vs the file manager and have tried removing all those differences and still cannot get the -i version to work when launched from the terminal - or to fail when launched from the file manager.

Additional info, csh works, but dash and zsh fail in the same way as bash.

The next step is probably to attach to bash to see why it is hanging.

[jonahgraham]

Launching with a PTY also resolves the problem:

		Process process = ProcessFactory.getFactory().exec(cmd, null, null, new PTY(Mode.TERMINAL));

[jonahgraham]

The issue (not cause yet) is that the bash process is stopped (i.e status is T):

$ ps aux
-- snip --
jonah    1652710  0.0  0.0  10332  3584 pts/23   T    09:56   0:00 /bin/bash -i -c /bin/echo echome
-- snip --

AFAICT it is in a stopped state because it received SIGTTIN. Issuing a SIGCONT to the process makes it continue along, e.g. issuing kill -SIGCONT 1652710 many times causes the process to complete properly.

---

SIGTTIN is raised when a process tries to read from a terminal when it is a background job. I'm not sure why bash tries to do this when Eclipse was launched from a terminal, but not when Eclipse was launched from a UI.

[jonahgraham]

@laeubi as mentioned on the call

[ilg-ul]

FYI, xpm, the tool that was the first to be reported to hang, should not run in interactive mode, since it receives all needed parameters on the command line. In other words, it should not try to read from stdin.

[jonahgraham]

I tend to agree, we shouldn't run in interactive mode and that would solve things. I am no longer sure there is a CDT bug here, i.e. CDT is doing the right thing and users of the API should be careful when inheriting stdin.

[ilg-ul]

As usual, my phrasing was confusing :-(

I wanted to tell that, in this context, xpm itself does not need to access the stdin; only if it is started without the mandatory properties on the command line, it checks if stdin and stdout are a TTY and starts a dialogue with the user.

This is different from the shell meaning of the interractive mode as defined by -i.

For reasons that are not under my control, the node environment installed by nvm is defined in .bashrc or .zshrc, and, when creating shell subprocesses that need to run node/npm/xpm, this .*rc file must be read in; without it these programs simply cannot run. The only option that I know to do this is via -i.

[jonahgraham]

SIGTTIN is raised when a process tries to read from a terminal when it is a background job. I'm not sure why bash tries to do this when Eclipse was launched from a terminal, but not when Eclipse was launched from a UI.

It does this because /dev/tty in inherited when launched from the terminal, but when launched from the GUI the /dev/tty is properly detached. This issue is not a CDT bug, but rather a user (of the API) error. The same thing happens if you run this with JDK's ProcessBuilder, eg:

	public void testInteractiveShell() throws IOException {
		Process process = new ProcessBuilder("/bin/bash", "-i", "-c", "/bin/echo echome").start();

		var reader = new BufferedReader(new InputStreamReader(process.getInputStream()));

		String line;
		List<String> outputLines = new ArrayList<>();
		while ((line = reader.readLine()) != null) {
			outputLines.add(line);
		}

		assertEquals(List.of("echome"), outputLines);

	}

Therefore this isn't a bug CDT is going to change.