[lldb-dev] [Bug 15278] New: LLDB on linux does not handle expressions that generate signals

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15278

            Bug ID: 15278
           Summary: LLDB on linux does not handle expressions that
                    generate signals
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at cs.uiuc.edu
          Reporter: daniel.malea at intel.com
    Classification: Unclassified

The test case in question is TestCallThatRestarts.py. The test not only fails,
but causes many tests that run after it to also fail. In order for the test
case to pass, we need proper handling of inferior threads on Linux
(llvm.org/PR14323) first.


The desired behaviour was explained by Jim Ingham in an email:

 If you call a function, and your process gets a signal while evaluating that
expression, AND the process handling for that signal is "no-stop" then getting
that signal should not cause the expression evaluation to be aborted, we should
just restart and it should go on its way.  If the process handling for that
signal is to print, we should still print that the signal was received, but
also go on our way.  And finally, if the signal is set to stop, then we should
stop when we get the signal, and obey the "unwind-on-error" setting and either
unwind the expression stack or stop at the point the signal was received
accordingly.

There is one other complexity here: the way we run expressions is a little
tricky.  We are trying to balance the user's desire that expression evaluation
run only the given expression, and not any other threads in the program, with
the fact that doing that can easily deadlock.  So we run expressions in two
phases.  We push the expression evaluation stack frame on the stack of the
currently selected thread, then we let just that thread run for some amount of
time.  If the expression hasn't completed in that time, then we interrupt the
process (call Halt), switch all the threads back on, and run the expression on
all threads.  There is also an optional timeout on the "all threads running"
phase, though for expression evaluation through the "expression" command or the
SB API's like SBFrame::EvaluateExpression the default timeout for the second
phase is infinite.  

This little two-step leads to all sorts of annoying corner cases, like we call
Halt and before we can get a chance to halt, the expression evaluation returns
successfully, or we were in the process of deciding that the signal stop we got
was not a reason for stopping, and are about to auto-continue when the one
thread execution times out, so we halt on one thread and continue on another...
 This patch was big because I was trying to work out all those issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130215/9418ac79/attachment.html>