Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

108 lines
3.1 KiB
Python
Raw Normal View History

# System modules
import os
import sys
# LLDB Modules
import lldb
from .lldbtest import *
from . import lldbutil
from lldbsuite.test.decorators import *
@skipIfRemote
@add_test_categories(["pexpect"])
class PExpectTest(TestBase):
NO_DEBUG_INFO_TESTCASE = True
PROMPT = "(lldb) "
def expect_prompt(self):
self.child.expect_exact(self.PROMPT)
[lldb/driver] Fix SIGTSTP handling Our SIGTSTP handler was working, but that was mostly accidental. The reason it worked is because lldb is multithreaded for most of its lifetime and the OS is reasonably fast at responding to signals. So, what happened was that the kill(SIGTSTP) which we sent from inside the handler was delivered to another thread while the handler was still set to SIG_DFL (which then correctly put the entire process to sleep). Sometimes it happened that the other thread got the second signal after the first thread had already restored the handler, in which case the signal handler would run again, and it would again attempt to send the SIGTSTP signal back to itself. Normally it didn't take many iterations for the signal to be delivered quickly enough. However, if you were unlucky (or were playing around with pexpect) you could get SIGTSTP while lldb was single-threaded, and in that case, lldb would go into an endless loop because the second SIGTSTP could only be handled on the main thread, and only after the handler for the first signal returned (and re-installed itself). In that situation the handler would keep re-sending the signal to itself. This patch fixes the issue by implementing the handler the way it supposed to be done: - before sending the second SIGTSTP, we unblock the signal (it gets automatically blocked upon entering the handler) - we use raise to send the signal, which makes sure it gets delivered to the thread which is running the handler This also means we don't need the SIGCONT handler, as our TSTP handler resumes right after the entire process is continued, and we can do the required work there. I also include a test case for the SIGTSTP flow. It uses pexpect, but it includes a couple of extra twists. Specifically, I needed to create an extra process on top of lldb, which will run lldb in a separate process group and simulate the role of the shell. This is needed because SIGTSTP is not effective on a session leader (the signal gets delivered, but it does not cause a stop) -- normally there isn't anyone to notice the stop. Differential Revision: https://reviews.llvm.org/D120320
2022-02-22 14:25:39 +01:00
def launch(
self,
executable=None,
extra_args=None,
timeout=60,
dimensions=None,
run_under=None,
post_spawn=None,
encoding=None,
use_colors=False,
):
# Using a log file is incompatible with using utf-8 as the encoding.
logfile = (
getattr(sys.stdout, "buffer", sys.stdout)
if (self.TraceOn() and not encoding)
else None
)
[lldb/driver] Fix SIGTSTP handling Our SIGTSTP handler was working, but that was mostly accidental. The reason it worked is because lldb is multithreaded for most of its lifetime and the OS is reasonably fast at responding to signals. So, what happened was that the kill(SIGTSTP) which we sent from inside the handler was delivered to another thread while the handler was still set to SIG_DFL (which then correctly put the entire process to sleep). Sometimes it happened that the other thread got the second signal after the first thread had already restored the handler, in which case the signal handler would run again, and it would again attempt to send the SIGTSTP signal back to itself. Normally it didn't take many iterations for the signal to be delivered quickly enough. However, if you were unlucky (or were playing around with pexpect) you could get SIGTSTP while lldb was single-threaded, and in that case, lldb would go into an endless loop because the second SIGTSTP could only be handled on the main thread, and only after the handler for the first signal returned (and re-installed itself). In that situation the handler would keep re-sending the signal to itself. This patch fixes the issue by implementing the handler the way it supposed to be done: - before sending the second SIGTSTP, we unblock the signal (it gets automatically blocked upon entering the handler) - we use raise to send the signal, which makes sure it gets delivered to the thread which is running the handler This also means we don't need the SIGCONT handler, as our TSTP handler resumes right after the entire process is continued, and we can do the required work there. I also include a test case for the SIGTSTP flow. It uses pexpect, but it includes a couple of extra twists. Specifically, I needed to create an extra process on top of lldb, which will run lldb in a separate process group and simulate the role of the shell. This is needed because SIGTSTP is not effective on a session leader (the signal gets delivered, but it does not cause a stop) -- normally there isn't anyone to notice the stop. Differential Revision: https://reviews.llvm.org/D120320
2022-02-22 14:25:39 +01:00
args = []
if run_under is not None:
args += run_under
args += [lldbtest_config.lldbExec, "--no-lldbinit"]
if not use_colors:
args.append("--no-use-colors")
for cmd in self.setUpCommands():
if "use-color false" in cmd and use_colors:
continue
args += ["-O", cmd]
if executable is not None:
args += ["--file", executable]
if extra_args is not None:
args.extend(extra_args)
env = dict(os.environ)
env["TERM"] = "vt100"
env["HOME"] = self.getBuildDir()
import pexpect
self.child = pexpect.spawn(
[lldb/driver] Fix SIGTSTP handling Our SIGTSTP handler was working, but that was mostly accidental. The reason it worked is because lldb is multithreaded for most of its lifetime and the OS is reasonably fast at responding to signals. So, what happened was that the kill(SIGTSTP) which we sent from inside the handler was delivered to another thread while the handler was still set to SIG_DFL (which then correctly put the entire process to sleep). Sometimes it happened that the other thread got the second signal after the first thread had already restored the handler, in which case the signal handler would run again, and it would again attempt to send the SIGTSTP signal back to itself. Normally it didn't take many iterations for the signal to be delivered quickly enough. However, if you were unlucky (or were playing around with pexpect) you could get SIGTSTP while lldb was single-threaded, and in that case, lldb would go into an endless loop because the second SIGTSTP could only be handled on the main thread, and only after the handler for the first signal returned (and re-installed itself). In that situation the handler would keep re-sending the signal to itself. This patch fixes the issue by implementing the handler the way it supposed to be done: - before sending the second SIGTSTP, we unblock the signal (it gets automatically blocked upon entering the handler) - we use raise to send the signal, which makes sure it gets delivered to the thread which is running the handler This also means we don't need the SIGCONT handler, as our TSTP handler resumes right after the entire process is continued, and we can do the required work there. I also include a test case for the SIGTSTP flow. It uses pexpect, but it includes a couple of extra twists. Specifically, I needed to create an extra process on top of lldb, which will run lldb in a separate process group and simulate the role of the shell. This is needed because SIGTSTP is not effective on a session leader (the signal gets delivered, but it does not cause a stop) -- normally there isn't anyone to notice the stop. Differential Revision: https://reviews.llvm.org/D120320
2022-02-22 14:25:39 +01:00
args[0],
args=args[1:],
logfile=logfile,
timeout=timeout,
dimensions=dimensions,
env=env,
encoding=encoding,
)
self.child.ptyproc.delayafterclose = timeout / 10
self.child.ptyproc.delayafterterminate = timeout / 10
[lldb/driver] Fix SIGTSTP handling Our SIGTSTP handler was working, but that was mostly accidental. The reason it worked is because lldb is multithreaded for most of its lifetime and the OS is reasonably fast at responding to signals. So, what happened was that the kill(SIGTSTP) which we sent from inside the handler was delivered to another thread while the handler was still set to SIG_DFL (which then correctly put the entire process to sleep). Sometimes it happened that the other thread got the second signal after the first thread had already restored the handler, in which case the signal handler would run again, and it would again attempt to send the SIGTSTP signal back to itself. Normally it didn't take many iterations for the signal to be delivered quickly enough. However, if you were unlucky (or were playing around with pexpect) you could get SIGTSTP while lldb was single-threaded, and in that case, lldb would go into an endless loop because the second SIGTSTP could only be handled on the main thread, and only after the handler for the first signal returned (and re-installed itself). In that situation the handler would keep re-sending the signal to itself. This patch fixes the issue by implementing the handler the way it supposed to be done: - before sending the second SIGTSTP, we unblock the signal (it gets automatically blocked upon entering the handler) - we use raise to send the signal, which makes sure it gets delivered to the thread which is running the handler This also means we don't need the SIGCONT handler, as our TSTP handler resumes right after the entire process is continued, and we can do the required work there. I also include a test case for the SIGTSTP flow. It uses pexpect, but it includes a couple of extra twists. Specifically, I needed to create an extra process on top of lldb, which will run lldb in a separate process group and simulate the role of the shell. This is needed because SIGTSTP is not effective on a session leader (the signal gets delivered, but it does not cause a stop) -- normally there isn't anyone to notice the stop. Differential Revision: https://reviews.llvm.org/D120320
2022-02-22 14:25:39 +01:00
if post_spawn is not None:
post_spawn()
self.expect_prompt()
for cmd in self.setUpCommands():
if "use-color false" in cmd and use_colors:
continue
self.child.expect_exact(cmd)
self.expect_prompt()
if executable is not None:
self.child.expect_exact("target create")
self.child.expect_exact("Current executable set to")
dotest: improvements to the pexpect tests Summary: While working on r370054, i've found it frustrating that the test output was compeletely unhelpful in case of failures. Therefore I've decided to improve that. In this I reuse the PExpectTest class, which was one of our mechanisms for running pexpect tests, but which has gotten orhpaned in the mean time. I've replaced the existing send methods with a "expect" method, which I've tried to design so that it has a similar interface to the expect method in regular non-pexpect dotest tests (as it essentially does something very similar). I've kept the ability to dump the transcript of the pexpect communication to stdout in the "trace" mode, as that is a very handy way to figure out what the test is doing. I've also removed the "expect_string" method used in the existing tests -- I've found this to be unhelpful because it hides the message that would be normally displayed by the EOF exception. Although vebose, this message includes some important information, like what strings we were searching for, what were the last bits of lldb output, etc. I've also beefed up the class to automatically disable the debug info test duplication, and auto-skip tests when the host platform does not support pexpect. This patch ports TestMultilineCompletion and TestIOHandlerCompletion to the new class. It also deletes TestFormats as it is not testing anything (definitely not formats) -- it was committed with the test code commented out (r228207), and then the testing code was deleted in r356000. Reviewers: teemperor, JDevlieghere, davide Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D66954 llvm-svn: 370449
2019-08-30 09:07:42 +00:00
self.expect_prompt()
def expect(self, cmd, substrs=None):
self.assertNotIn("\n", cmd)
# If 'substrs' is a string then this code would just check that every
# character of the string is in the output.
assert not isinstance(substrs, str), "substrs must be a collection of strings"
self.child.sendline(cmd)
if substrs is not None:
for s in substrs:
self.child.expect_exact(s)
self.expect_prompt()
def quit(self, gracefully=True):
self.child.sendeof()
self.child.close(force=not gracefully)
self.child = None
def cursor_forward_escape_seq(self, chars_to_move):
"""
Returns the escape sequence to move the cursor forward/right
by a certain amount of characters.
"""
return b"\x1b\[" + str(chars_to_move).encode("utf-8") + b"C"