[+lldb-dev]
Hello Steve,
thanks for the report.
The fact that you see the rendezvous breakpoint being hit many times is not
surprising. We get those every time the library is loaded (we need that to
load relevant debug info and set potential breakpoints). However, they
should generally not be su
It is interesting that the stop reason on the thread that stopped is "trace".
That's what you would expect returning from the single-step to step over the
breakpoint. But it looks like we got a signal while single-stepping, but the
stop reason was misreported by somebody.
Jim
> On Apr 17, 2
Pavel asked for a dump of gdb-remote commands. I got that and ran it through the gdbremote decoder, and trimmed to include what looks like the last successful continue after breakpoint and then the halt on dlopen. Both cases stop on signal 5.After the stop message the debugger issues two binary r
It's a bit of a wild guess, but is it possible that you (or one of the
libraries you use) are doing anything with signals (SIGALRM or such?). I
think I remember looking at the code handling the server-side ignored
signal handling and thinking that it could go wrong if you get a signal
while doing a
Ding! That’s it. This program does use SIGALRM. I wouldn’t have thought it
would be enabled at this point, but apparently it is because I got lots of
sigalarm halts during the .so loading.
Further, if I run in lldb with
process handle -n false -p false -s false SIGALRM
then the debugger se
