[lldb-dev] Linux issues where I am not getting breakpoints...

Wed Apr 12 15:33:38 PDT 2017

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 <clayborg at 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 <tberghammer at google.com <mailto:tberghammer at 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 <clayborg at gmail.com <mailto:clayborg at 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 <labath at google.com <mailto:labath at google.com>> wrote:
>>> 
>>> 
>>> 
>>> On 11 April 2017 at 15:56, Greg Clayton <clayborg at gmail.com <mailto:clayborg at gmail.com>> wrote:
>>> 
>>>> On Apr 11, 2017, at 5:33 AM, Pavel Labath <labath at google.com <mailto:labath at 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
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170412/9844ad1f/attachment-0001.html>