Yes, that's exactly what I see, thanks a lot! Does it explain why I see SIGILL reappear when I let process continue after mmap execution? I.e. do I need to look into this more? Thanks,Eugene > From: lab...@google.com > Date: Thu, 8 Oct 2015 09:13:37 +0100 > Subject: Re: [lldb-dev] Thread resumes with stale signal after executing > InferiorCallMmap > To: eugen...@hotmail.com > CC: lldb-dev@lists.llvm.org; jing...@apple.com > > Hi, > > I believe the SIGILL problem you are referring to is the problem > described in bug <https://llvm.org/bugs/show_bug.cgi?id=23659>. This > was fixed in r244875, but unfortunately, this was after 3.7 branch so > this patch did not make it there. I recommend to try the master > branch, I think this should work for you now (and do let me know if > the problem persists). > > pl > > On 8 October 2015 at 00:20, Jim Ingham via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > > >> On Oct 7, 2015, at 4:06 PM, Eugene Birukov <eugen...@hotmail.com> wrote: > >> > >> 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. > > > > It doesn't happen on OS X, though when it comes to signal handling in the > > debugger OS X is an odd fish... > > > >> > >> 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?). > > > > The signal that you stop with is not necessarily the one you are going to > > resume with. For instance, if you use "process handle SIG_SOMESIG -p 0" to > > tell lldb not to propagate the signal, then the resume signal will be > > nothing, even though the stop signal is SIG_SOMESIG. > > > >> 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. > > > > When the expression evaluation completes, the StopInfo from the last > > "natural" stop should be put back in place in the thread. After all, if > > you hit a breakpoint, run an expression, then ask why that thread stopped, > > you want to see "hit a breakpoint" not "ran a function call". Sounds like > > that is failing somehow. > > > > Jim > > > > > >> > >> > 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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
