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

Reply via email to