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
