We should increase the timeout for this command only. We can do that. Thanks for the pointer, that will make fixing things much easier!
> On Apr 13, 2017, at 5:48 AM, Tamas Berghammer <tbergham...@google.com> wrote: > > 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. > > Tamas > > On Wed, Apr 12, 2017 at 11:33 PM Greg Clayton <clayb...@gmail.com > <mailto:clayb...@gmail.com>> wrote: > 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. > > Greg > >> On Apr 12, 2017, at 10:42 AM, Greg Clayton <clayb...@gmail.com >> <mailto:clayb...@gmail.com>> wrote: >> >> 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. >> >> Also, log_channels in lldb-gdbserver.cpp is using a llvm::StringRef >> incorrectly: >> >> case 'c': // Log Channels >> if (optarg && optarg[0]) >> log_channels = StringRef(optarg); >> break; >> >> 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>". >> >> Greg >> >>> On Apr 12, 2017, at 10:05 AM, Tamas Berghammer <tbergham...@google.com >>> <mailto:tbergham...@google.com>> wrote: >>> >>> 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). >>> >>> Note: You can enable them by setting LLDB_SERVER_LOG_CHANNELS and >>> LLDB_DEBUGSERVER_LOG_FILE environment variables before starting lldb. >>> >>> On Wed, Apr 12, 2017 at 5:11 PM Greg Clayton <clayb...@gmail.com >>> <mailto:clayb...@gmail.com>> wrote: >>> 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: >>> >>> $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 >>> >>> that gets sent these days. I will try removing this and seeing if it fixes >>> anything. >>> >>> 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. >>> >>> Greg >>> >>>> On Apr 11, 2017, at 8:26 AM, Pavel Labath <lab...@google.com >>>> <mailto:lab...@google.com>> wrote: >>>> >>>> >>>> >>>> On 11 April 2017 at 15:56, Greg Clayton <clayb...@gmail.com >>>> <mailto:clayb...@gmail.com>> wrote: >>>> >>>>> On Apr 11, 2017, at 5:33 AM, Pavel Labath <lab...@google.com >>>>> <mailto:lab...@google.com>> wrote: >>>>> >>>>> 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 LoadModuleAtAddress calls happen between the $T and $c packets in >>>>> the gdb-remote packet sequence. >>>>> >>>>> The module loading should be synchronous, so I think the problem lies >>>>> elsewhere. >>>>> >>>>> 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.. >>>> >>>> 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? >>>> >>>> >>>> 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. >>>> >>>> pl >>> >> >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
