I will have another look tomorrow.
On Thu, Mar 31, 2016 at 11:56 AM Eran Ifrah wrote:
> Ping...
>
> On Mon, Mar 28, 2016 at 10:19 PM, Eran Ifrah wrote:
>
>> Sorry, the current status is that lldb-server is no longer needed,
>> however the debuggee process hangs and the lldb.exe is "froze" (i.e.
OK, I got the picture, thanks a lot!
> What is it that you are trying to do anyway?
Well, target termination during detach is unexpected, so my customers might get
confused. Fortunately I am in control of the target program too, so I'll just
ignore SIGHUP for the time being.
Thanks,Eugene
Ping...
On Mon, Mar 28, 2016 at 10:19 PM, Eran Ifrah wrote:
> Sorry, the current status is that lldb-server is no longer needed, however
> the debuggee process hangs and the lldb.exe is "froze" (i.e. it does not
> accept user input)
>
> Here is the backtrace: http://pastebin.com/mbLFgCA6
> I wil
> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev
> wrote:
>
> Hello all,
> I am currently working on enabling Intel (R) Processor Trace
> collection for lldb. I have done some previous discussions in this mailing
> list on this topic but just to summarize , the pa
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);
Hello all,
I am currently working on enabling Intel (R) Processor Trace
collection for lldb. I have done some previous discussions in this mailing
list on this topic but just to summarize , the path we chose was to
implement raw trace collection in lldb and the trace will be decoded
o
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 runn
