[lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

[Jim Ingham via lldb-dev]

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 at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev