Hi Pavel, Eugene, here is a testcase that demonstrates the problem. The code
that sets up sigalrm in main() is the same as the program I have been debugging
except that I’ve reduced the interval in this testcase. In the original, as
per the comment, the interval is .8 seconds.
When I run this
+Eugene, who wrote the signal-skipping code
Cool, I'm glad we got to the bottom of this.
At this point, I *think* we should be able to reproduce the issue
ourselves, but a self-contained reproducer would definitely make it easier
for us and would be appreciated, particularly as there are still 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
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
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 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
[+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
