<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">We should increase the timeout for this command only. We can do that. Thanks for the pointer, that will make fixing things much easier!<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 13, 2017, at 5:48 AM, Tamas Berghammer <<a href="mailto:tberghammer@google.com" class="">tberghammer@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I seen a similar issue when trying to debug an application with a lot of shared libraries (1000+) and in that case the problem was that lldb-server was too slow to respond what caused a connection timeout in lldb. Increasing plugin.process.gdb-remote.packet-timeout fixed the problem for me but it would be great if we can make the jModulesInfo packet faster in lldb-server.<div class=""><br class=""></div><div class="">Tamas<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Apr 12, 2017 at 11:33 PM Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">So the issue is with jModulesInfo. If it is too large we end up losing connection. Not sure if this is on the send or receive side yet. But if I comment out support for this packet, my debug sessions works just fine.</div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Greg</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Apr 12, 2017, at 10:42 AM, Greg Clayton <<a href="mailto:clayborg@gmail.com" class="gmail_msg" target="_blank">clayborg@gmail.com</a>> wrote:</div><br class="gmail_msg m_-444704396498198427Apple-interchange-newline"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">What I now believe is happening is lldb-server is exiting for some reason and then the process just runs and still shows the output in LLDB because we hooked up the STDIO. I see lldb-server exits with an exit code of 0, but no command had been sent to terminate it. I will track that down.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Also, log_channels in lldb-gdbserver.cpp is using a llvm::StringRef incorrectly:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"> case 'c': // Log Channels<br class="gmail_msg"> if (optarg && optarg[0])<br class="gmail_msg"> log_channels = StringRef(optarg);<br class="gmail_msg"> break;<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg">Bad! This is exactly when we shouldn't be using llvm::StringRef. optarg is a static variable and can change if there are any arguments after "-c <args>".</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Greg</div><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Apr 12, 2017, at 10:05 AM, Tamas Berghammer <<a href="mailto:tberghammer@google.com" class="gmail_msg" target="_blank">tberghammer@google.com</a>> wrote:</div><br class="gmail_msg m_-444704396498198427Apple-interchange-newline"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">If the process is restarted by lldb-server then "posix ptrace" should have some indication about it. Also "posix process" and "posix thread" can be useful to understand the bigger picture (all of them in lldb-server).<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Note: You can enable them by setting LLDB_SERVER_LOG_CHANNELS and LLDB_DEBUGSERVER_LOG_FILE environment variables before starting lldb.</div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Apr 12, 2017 at 5:11 PM Greg Clayton <<a href="mailto:clayborg@gmail.com" class="gmail_msg" target="_blank">clayborg@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">What is actually happening is we are stopped and handling the EntryBreakpoint and are in the process of trying to load all shared libraries, and then a signal (I am guessing) comes into the lldb-server and causes the target to resume. Not sure if that is due to the signal passing packet:<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">$QPassSignals:0e;1b;20;21;22;23;24;25;26;27;28;29;2a;2b;2c;2d;2e;2f;30;31;32;33;34;35;36;37;38;39;3a;3b;3c;3d;3e;3f;40#69</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">that gets sent these days. I will try removing this and seeing if it fixes anything.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Is there any logging I can enabled in lldb-server to catch the resume? I haven't looked at the code but I finally proved what was happening last night (target resumes while we are stopped at a breakpoint somehow). The program runs and exits and when the shared libraries are finally done loading, there is no connection to speak to.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Greg</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Apr 11, 2017, at 8:26 AM, Pavel Labath <<a href="mailto:labath@google.com" class="gmail_msg" target="_blank">labath@google.com</a>> wrote:</div><br class="gmail_msg m_-444704396498198427m_-4392110731067642832Apple-interchange-newline"><div class="gmail_msg"><br class="gmail_msg m_-444704396498198427m_-4392110731067642832Apple-interchange-newline"><br style="font-family:Menlo-Regular;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><div class="gmail_quote gmail_msg" style="font-family:Menlo-Regular;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On 11 April 2017 at 15:56, Greg Clayton<span class="gmail_msg m_-444704396498198427m_-4392110731067642832Apple-converted-space"> </span><span dir="ltr" class="gmail_msg"><<a href="mailto:clayborg@gmail.com" class="gmail_msg" target="_blank">clayborg@gmail.com</a>></span><span class="gmail_msg m_-444704396498198427m_-4392110731067642832Apple-converted-space"> </span>wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Apr 11, 2017, at 5:33 AM, Pavel Labath <<a href="mailto:labath@google.com" class="gmail_msg" target="_blank">labath@google.com</a>> wrote:</div><br class="gmail_msg m_-444704396498198427m_-4392110731067642832m_-8841469701513024722Apple-interchange-newline"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">Are you sure this is not just an artifact of stdio buffering? I tried the same experiment, but I placed a real log statement, and I could see that all the <span style="font-size:12.8px" class="gmail_msg">LoadModuleAtAddress calls happen between the $T and $c packets in the gdb-remote packet sequence. </span><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">The module loading should be synchronous, so I think the problem lies elsewhere.</span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:12.8px" class="gmail_msg">What is the nature of the breakpoint that is not getting hit? Can you provide a repro case? The only bug like this that I am aware of is that we fail to hit breakpoints in global constructors in shared libraries, but that hasn't worked even in 3.8..</span></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span>I unfortunately can't attach a repro case. I will be able to track this down, just need some pointers. I did notice that I wasn't able to hit breakpoints in global constructors though... Do we know why? On Mac, we get notified of shared libraries as they load so we never miss anything. Why are we not able to get the same thing with linux?<div class="gmail_msg"><div class="gmail_msg m_-444704396498198427m_-4392110731067642832h5"><br class="gmail_msg"></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It looks like we are intercepting the library load too late, but I haven't investigated yet how to fix it. It's definitely possible (this works fine in gdb), but I don't know how, as the dynamic linker is still a big unknown to me. FWIW, I think I'll be messing with the dynamic loader plugin soon(ish), so I'll try to fix this then.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">pl</div></div></div></blockquote></div><br class="gmail_msg"></div></div></blockquote></div>
</div></blockquote></div><br class="gmail_msg"></div></div></div></blockquote></div><br class="gmail_msg"></div></div></blockquote></div></div></div>
</div></blockquote></div><br class=""></div></body></html>