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
