Even on Linux call to InferiorCallMmap does not fail consistently. In many cases it survives. I just happened to have 100% repro on this specific breakpoint in my specific problem. I.e. the burden of investigation is on me, since I cannot share my program. But I am not looking at this SIG_ILL yet. Whatever the problem is with mmap - the client must not carry this signal past expression evaluation. I.e. I believe that we can construct any arbitrary function that causes signal, call it from evaluate expression, and then continue would fail. I suspect that this problem might be applicable to any POSIX platform. As it turned out, my initial analysis was incorrect. m_resume_signal is calculated from StopInfo::m_value (now I wonder why do we need two fields for that?). And after mmap call, m_stop_info on the thread is null. So, my current theory is that there is an event with SIG_ILL that is stuck in the broadcaster and is picked up and processed much later.
> Subject: Re: [lldb-dev] Thread resumes with stale signal after executing > InferiorCallMmap > From: jing...@apple.com > Date: Wed, 7 Oct 2015 15:08:18 -0700 > CC: lldb-dev@lists.llvm.org > To: eugen...@hotmail.com > > Does it only happen for InferiorCallMmap, or does an expression evaluation > that crashes in general set a bad signal on resume? I don't see this > behavior in either case on OS X, so it may be something in the Linux support. > Be interesting to figure out why it behaves this way on Linux, so whatever > we do we're implementing it consistently. > > Jim > > > > > On Oct 7, 2015, at 12:03 PM, Eugene Birukov via lldb-dev > > <lldb-dev@lists.llvm.org> wrote: > > > > Hi, > > > > I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint and > > if I call SBFrame::EvaluateExpression() there, when I let it go it > > terminates with SIG_ILL on an innocent thread. I dug up into this, and > > there seems to be two independent problems there, this mail is about the > > second one. > > > > • EvaluateExpression() calls Process::CanJIT() which in turn executes > > mmap() on the inferior. This mmap gets SIG_ILL because execution starts at > > address which is 2 bytes before the very first mmap instruction. I am still > > looking why LLDB server decided to do that - I am pretty sure that the > > client asked to set the program counter to correct value. > > • So, the thread execution terminates and the signal is recorded on > > Thread::m_resume_signal. This field is not cleared during > > Thread::RestoreThreadStateFromCheckpoint() and fires when I resume the > > program after breakpoint. > > > > So, what would be the best way to deal with the situation? Should I add > > "resume signal" field to ThreadStateCheckpoint? Or would StopInfo be a > > better place for that? Or something else? > > > > Thanks, > > Eugene > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
