[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
Skip test on earlier clang versions
[LLDB] Skip TestProcessIOHandlerInterrupt Arm/AArch64 LinuxThis patch skips TestProcessIOHandlerInterrupt on Arm/AArch64.PExpect tests are not stable when run in containerized machine.
[lldb] Increase timeout in TestProcessIOHandlerInterruptThe small value was not meant to be checked in.
[lldb] Fix TestProcessIOHandlerInterrupt.py for macosOn darwin, we don't completely suppress the signal used to interrupt theinferior. The underlying read syscall returns EINTR, which causes prema
[lldb] Fix TestProcessIOHandlerInterrupt.py for macosOn darwin, we don't completely suppress the signal used to interrupt theinferior. The underlying read syscall returns EINTR, which causes prematuretermination of the input loop.Work around that by hand-rolling an EINTR-resistant version of getline.
[lldb] Fix ^C handling in IOHandlerProcessSTDIOD120762 accidentally moved the interrupt check into the block which wasreading stdio. This meant that a ^C only took effect after a regularcharacter
[lldb] Fix ^C handling in IOHandlerProcessSTDIOD120762 accidentally moved the interrupt check into the block which wasreading stdio. This meant that a ^C only took effect after a regularcharacter has been pressed.This patch fixes that and adds a (pexpect) test.Differential Revision: https://reviews.llvm.org/D121912
[lldb] Skip TestIOHandlerPythonREPLSigint if *host* is linuxThe current dectorator (@skipIfLinux) will skip the test if the lldbplatform is the linux platform, but the issue is with the OS that ll
[lldb] Skip TestIOHandlerPythonREPLSigint if *host* is linuxThe current dectorator (@skipIfLinux) will skip the test if the lldbplatform is the linux platform, but the issue is with the OS that lldbis running on, not the OS that lldb is debugging. Update the decoratorto skip the test if the host is Linux.Thank you Ted Woodward for pointing this out.
[LLDB] Skip TestIOHandlerPythonREPLSigint.py on AArch64/LinuxTestIOHandlerPythonREPLSigint.py is running falky on AArch64/Linuxbuildbot failing randomly. Skipping it for AArch64/Linux as well.
[LLDB] Skip TestIOHandlerPythonREPLSigint.py on Arm/LinuxTestIOHandlerPythonREPLSigint.py is failing on Arm/Linux buildbot. I ammarking it as skip for now.
[lldb] Fix that the embedded Python REPL crashes if it receives SIGINTWhen LLDB receives a SIGINT while running the embedded Python REPL itcurrently just crashes in ScriptInterpreterPythonImpl::In
[lldb] Fix that the embedded Python REPL crashes if it receives SIGINTWhen LLDB receives a SIGINT while running the embedded Python REPL itcurrently just crashes in ScriptInterpreterPythonImpl::Interrupt with anerror such as the one below: Fatal Python error: PyThreadState_Get: the function must be called with the GIL held, but the GIL is released (the current Python thread state is NULL)The faulty code that causes this error is this part ofScriptInterpreterPythonImpl::Interrupt: PyThreadState *state = PyThreadState_GET(); if (!state) state = GetThreadState(); if (state) { long tid = state->thread_id; PyThreadState_Swap(state); int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt);The obvious fix I tried is to just acquire the GIL before this code isrunning which fixes the crash but the KeyboardInterrupt we want to raiseimmediately is actually just queued and would only be raised once thenext line of input has been parsed (which e.g. won't interrupt Pythoncode that is currently waiting on a timer or IO from what I can see).Also none of the functions we call here is marked as safe to be calledfrom a signal handler from what I can see, so we might still end upcrashing here with some bad timing.Python 3.2 introduced PyErr_SetInterrupt to solve this and the functiontakes care of all the details and avoids doing anything that isn't safeto do inside a signal handler. The only thing we need to do is tomanually setup our own fake SIGINT handler that behaves the same way asthe standalone Python REPL signal handler (which raises aKeyboardInterrupt).From what I understand the old code used to work with Python 2 so I keptthe old code around until we officially drop support for Python 2.There is a small gap here with Python 3.0->3.1 where we might still becrashing, but those versions have reached their EOL more than a decadeago so I think we don't need to bother about them.Differential revision: https://reviews.llvm.org/D104886
Revert "[lldb] Fix that the embedded Python REPL crashes if it receives SIGINT"This reverts commit cef1e07cc6d00b5b429d77133201e1f404a8023c.It broke the windows bot.
[lldb] Fix that the embedded Python REPL crashes if it receives SIGINTWhen LLDB receives a SIGINT while running the embedded Python REPL it currentlyjust crashes in `ScriptInterpreterPythonImpl::I
[lldb] Fix that the embedded Python REPL crashes if it receives SIGINTWhen LLDB receives a SIGINT while running the embedded Python REPL it currentlyjust crashes in `ScriptInterpreterPythonImpl::Interrupt` with an error such asthe one below:```Fatal Python error: PyThreadState_Get: the function must be called with the GILheld, but the GIL is released (the current Python thread state is NULL)```The faulty code that causes this error is this part of `ScriptInterpreterPythonImpl::Interrupt`:``` PyThreadState *state = PyThreadState_GET(); if (!state) state = GetThreadState(); if (state) { long tid = state->thread_id; PyThreadState_Swap(state); int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt);```The obvious fix I tried is to just acquire the GIL before this code is runningwhich fixes the crash but the `KeyboardInterrupt` we want to raise immediatelyis actually just queued and would only be raised once the next line of input hasbeen parsed (which e.g. won't interrupt Python code that is currently waiting ona timer or IO from what I can see). Also none of the functions we call here ismarked as safe to be called from a signal handler from what I can see, so wemight still end up crashing here with some bad timing.Python 3.2 introduced `PyErr_SetInterrupt` to solve this and the function takescare of all the details and avoids doing anything that isn't safe to do inside asignal handler. The only thing we need to do is to manually setup our own fakeSIGINT handler that behaves the same way as the standalone Python REPL signalhandler (which raises a KeyboardInterrupt).From what I understand the old code used to work with Python 2 so I kept the oldcode around until we officially drop support for Python 2.There is a small gap here with Python 3.0->3.1 where we might still be crashing,but those versions have reached their EOL more than a decade ago so I think wedon't need to bother about them.Reviewed By: JDevlieghereDifferential Revision: https://reviews.llvm.org/D104886