It might be also possible to run an expression that will route stdin/stdout/stderr to /dev/null before detaching if we know that we have a master/slave pty hooked up the the inferior's in/out/err. We could run an expression like:
int fd = open("/dev/null", O_RDWR); close(0); close(1); close(2); dup2(fd, 0); dup2(fd, 1); dup2(fd, 2); Then the program could continue normally? So this might need to be part of detach code, but it should only be done if we used a pty. One other thing to try is to write a 0x04 to the master side of the pty. Since the master/slave is emulating a terminal, this is how you shut it down as if you just close the master side, and if the other process is doing a fgets(...) from the slave side, it won't cause the slave to exit, but writing the EOF (0x04) byte to the master side _will_ cause the fgets(...) to exit on the other side. Greg > On Mar 31, 2016, at 1:16 AM, Pavel Labath via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > We are not sending the SIGHUP, it is automatically getting sent by the > OS when the master end of the pty gets closed. The reason you are not > seeing this in the attach scenario is that we do not intercept > inferior stdio in this case (it's not possible, or desirable, since > the process is already running). This is also the reason > SBProcess.GetSTDOUT does not return anything in the attach scenario. I > am not familiar with the details of the Mac implementation and I > cannot tell you why is this not happening there. > I guess one way to fix this would be to have a special mode of > starting the inferior without a controlling terminal, but I am not > sure if this would be a generally useful feature. What is it that you > are trying to do anyway? > > pl > > On 30 March 2016 at 23:03, Eugene Birukov <eugen...@hotmail.com> wrote: >> Just a wild guess - is this SIGHUP because stdin/stdout are broken? I.e. the >> debugger closes its pty's on detach and that causes the signal? >> What is the behavior on MAC? >> >> ________________________________ >> To: lab...@google.com >> Date: Wed, 30 Mar 2016 14:49:33 -0700 >> CC: lldb-dev@lists.llvm.org >> Subject: Re: [lldb-dev] SBProcess::Detach kills target >> From: lldb-dev@lists.llvm.org >> >> >> Right, my bad. The problem was that when debugger detaches the stdio does >> not go anywhere so I failed to see my printf. >> >> Still, is this how it is supposed to be? I naively assume that if we don't >> send SIGHUP in attach scenario we should not send it in launch scenario too. >> >> Thanks, >> Eugene >> >>> From: lab...@google.com >>> Date: Wed, 30 Mar 2016 10:22:33 +0100 >>> Subject: Re: [lldb-dev] SBProcess::Detach kills target >>> To: eugen...@hotmail.com >>> CC: jing...@apple.com; lldb-dev@lists.llvm.org >>> >>> So I have made a small test program (which does nothing but spin in a >>> loop), and indeed it is the SIGHUP that kills it after detach. If the >>> test program blocks the signal, then it continues running even after >>> detach: >>> $ cat a.c >>> #include <unistd.h> >>> #include <signal.h> >>> >>> int main() { >>> signal(SIGHUP, SIG_IGN); >>> for (;;) sleep(1); >>> } >>> $ cc a.c -g >>> $ ps -A | grep a.out >>> $ ~/ll/build/dbg/bin/lldb ./a.out >>> (lldb) target create "./a.out" >>> Current executable set to './a.out' (x86_64). >>> (lldb) b 6 >>> Breakpoint 1: where = a.out`main + 19 at a.c:6, address = >>> 0x0000000000400590 >>> (lldb) r >>> Process 13416 launched: './a.out' (x86_64) >>> Process 13416 stopped >>> * thread #1: tid = 13416, 0x0000000000400590 a.out`main + 19 at a.c:6, >>> name = 'a.out', stop reason = breakpoint 1.1 >>> frame #0: 0x0000000000400590 a.out`main + 19 at a.c:6 >>> 3 >>> 4 int main() { >>> 5 signal(SIGHUP, SIG_IGN); >>> -> 6 for (;;) sleep(1); >>> 7 } >>> (lldb) detach >>> Process 13416 detached >>> (lldb) q >>> $ ps -A | grep a.out >>> 13416 ? 00:00:00 a.out >>> >>> >>> On 29 March 2016 at 18:38, Eugene Birukov <eugen...@hotmail.com> wrote: >>>> I believe this is not SIGHUP on debugger exit. I am using my own C++ >>>> program >>>> that calls into LLDB API. So, this program is still alive after calling >>>> SBProcess::Detach() but the target dies. Also, the target intercepts >>>> SIGHUP >>>> to do cleanup before exiting. I put printf there, it was not hit. >>> The fact whether your program is alive irrelevant. What matters is >>> that by cleaning up the process structure, we will also close the >>> master end of the pty used for inferior communication, and this is >>> what causes the SIGHUP. For that reason you also cannot use a printf >>> to do diagnostics as the output has nowhere to go. Note that lldb's >>> behavior here will be different from gdb as gdb does not do stdio >>> redirection, and has the inferior share the pty with the debugger (in >>> which case your program will die when you close the terminal window). >>> >>>> >>>> I tried interactive LLDB, the target is not there: >>>> >>>> Process 49145 stopped >>>> * thread #1: tid = 49145, ..., stop reason = signal SIGSTOP >>>> frame #0: 0x00007ffff6a5bbed libc.so.6 at syscall-template.S:81 >>>> (lldb) detach >>>> Process 49145 detached >>>> (lldb) q >>>> eugene@EUGENEBI-L1:~/tmp$ ps >>>> PID TTY TIME CMD >>>> 30714 pts/17 00:00:00 bash >>>> 49259 pts/17 00:00:00 ps >>> Note that the inferior will not show up here even if it exists, as ps >>> will only list the processes with the same tty, but at this point the >>> inferior process has no tty. >>> >>> Good luck with your investigations. >>> >>> pl >> >> _______________________________________________ lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev