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 wrote:
>
> I seen a similar issue when trying to debug an application with a lot of
> shared libraries (1000+)
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 w
While definitely not a prime example of StringRef usage, it is not strictly
a bug either. Future calls of getopt will modify the value of optarg, but
the actual string it points to (will have pointed to) remains unchanged as
that is just some member of the initial argv array.
That said, I have no
On Wed, Apr 12, 2017 at 10:43 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> 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 wit
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 wrote:
>
> What I now beli
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,
BTW, lldb has a setting:
settings set target.process.extra-startup-command
In the Process GDBRemote case if this is set lldb sends whatever packet you
specify to the stub before starting the normal sequence.
We added support in debugserver for a QSetLogging packet, which we use like:
QSetLogg
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_DEBUGSERV
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:
$QPass
On 11 April 2017 at 15:56, Greg Clayton wrote:
>
> On Apr 11, 2017, at 5:33 AM, Pavel Labath 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
See https://bugs.llvm.org/show_bug.cgi?id=25806 for details about why we
can't set breakpoint in the static initializer (it is an LLDB bug).
For your investigation a few pointers/guesses (assuming it is not some
stdout displaying issue what I consider unlikely based on your description):
* Do your
> On Apr 11, 2017, at 5:33 AM, Pavel Labath 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-rem
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
13 matches
Mail list logo
