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

Reply via email to