Odd signal behavior when starting certain command line applications via Debugger

[anevilyak]

If one runs e.g. /system/apps/Debugger /bin/info from Terminal, waits for the debugger window to come up, then closes it and chooses to resume the app at the prompt, the app subsequently crashes due to a stack overflow. From the corresponding backtrace, it's not entirely clear what's going on though, the app seems to keep getting handed a SIGTTIN while it's in the process of handling the previous one. This behavior only seems to be observable with apps that do something curses-based though.

The only obvious difference that comes to mind is that Debugger spawns the requested app via load_image(), while in normal circumstances they're run via fork/exec from bash. In any case, the corresponding crash report for info is attached (in compressed form, since it winds up being 25MB due to the size of the backtrace). I've assigned it to System due to not being certain as to the actual culprit here.

[bonefish]

I think the issue might be the following: When the shell starts Debugger, it creates a new process group. Debugger starts the debugged program in the same process group. When Debugger quits, the shell reclaims the terminal (it only knows Debugger, but not its child), i.e. /bin/info's process group becomes a background process group. Trying to read something from the terminal therefore causes a SIGTTIN to be sent. I don't know off the top of my head, whether SIGTTIN would have to be blocked while the signal handler is executed (unless explicitly disabled via SA_NODEFER), but the recursion suggests that it isn't.

Generally, it is entirely possible that this use case simply cannot work due to the missing relationship between shell and debugged program. I tried with gdb on Linux but I didn't manage to detach and quit gdb while the debugged program continued to run. kdbg creates a new terminal for the debugged program (and so do the debuggers in eclipse and QtCreator), so I don't know how to reproduce the situation on Linux.

[anevilyak]

Replying to bonefish:

Generally, it is entirely possible that this use case simply cannot work due to the missing relationship between shell and debugged program. I tried with gdb on Linux but I didn't manage to detach and quit gdb while the debugged program continued to run. kdbg creates a new terminal for the debugged program (and so do the debuggers in eclipse and QtCreator), so I don't know how to reproduce the situation on Linux.

Does that imply that we potentially need to do something similar? That would be necessary anyways if we want to be able to support the case where one starts Debugger via Deskbar or some other entirely graphical means, and then wants to run and debug a terminal app via Start New Team, no?

[bonefish]

To clarify: The mentioned IDEs have a console window/view. I'm not sure whether it is even a full-blown TTY. The debugged program certainly won't survive quitting the IDE. kdbg starts an xterm which it closes when quitting. So the situation is the same. I.e. being able to resume the debugged program after quitting the debugger doesn't seem to be a general expectation. At least when it was started by the debugger.

We could relatively easily get around the restriction, though. A debug command line program could be created that clones debugger's command line options. It would start Debugger in the background (i.e. not associated with the TTY). When attaching the debugger to a running program, debug could quit immediately after sending the command line arguments to Debugger. When a debugged program is to be launched first, debug would launch the debugged program (upon Debugger's request) and continue running (respectively waiting) until the program quits and Debugger's team window has been closed (allows restarting the program). Even after quitting Debugger debug would continue until the program terminates. This would fix the issue this ticket is about.

Regarding Debugger starting a new Terminal, that can certainly be added as an option.

Anyway, I don't find either restriction (having to run a CLI program with Debugger from the command line, and not being able to resume a CLI program when quitting Debugger) that bad. IOW low priority IMO.

[luroh]

Moving Debugger related tickets out of R1 milestone (Prop #14).