summaryrefslogtreecommitdiff
path: root/lldb/test/API/functionalities/bt-interrupt/TestInterruptBacktrace.py
AgeCommit message (Collapse)Author
2025-05-27[lldb][NFC] update API tests which skip/expect-fail armJason Molenda
The architectures provided to skipIf / expectedFail are regular expressions (v. _match_decorator_property() in decorators.py so on Darwin systems "arm64" would match the skips for "arm" (32-bit Linux). Update these to "arm$" to prevent this, and also update three tests (TestBuiltinFormats.py, TestCrossDSOTailCalls.py, TestCrossObjectTailCalls.py) that were skipped for arm64 via this behavior, and need to be skipped or they will fail. This was moviated by the new TestDynamicValue.py test which has an expected-fail for arm, but the test was passing on arm64 Darwin resulting in failure for the CIs.
2023-05-25[NFC][Py Reformat] Reformat python files in lldbJonas Devlieghere
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460
2023-05-22[LLDB] Fix missing import in TestInterruptBacktrace.pyMuhammad Omair Javaid
This fixed missing import of lldbsuite.test.decorators in TestInterruptBacktrace.py.
2023-05-22[LLDB] Skip TestInterruptBacktrace.py on Arm/LinuxMuhammad Omair Javaid
TestInterruptBacktrace.py started randonmly failing on Arm/Linux buildbot since e19387e6936c. This patch marks it skipped. Differential Revision: https://reviews.llvm.org/D150236
2023-05-11We can't let GetStackFrameCount get interrupted or it will give theJim Ingham
wrong answer. Plus, it's useful in some places to have a way to force the full stack to be created even in the face of interruption. Moreover, most of the time when you're just getting frames, you don't need to know the number of frames in the stack to start with. You just keep calling Thread::GetStackFrameAtIndex(index++) and when you get a null StackFrameSP back, you're done. That's also more amenable to interruption if you are doing some work frame by frame. So this patch makes GetStackFrameCount always return the full count, suspending interruption. I also went through all the places that use GetStackFrameCount to make sure that they really needed the full stack walk. In many cases, they did not. For instance frame select -r 10 was getting the number of frames just to check whether cur_frame_idx + 10 was within the stack. It's better in that case to see if that frame exists first, since that doesn't force a full stack walk, and only deal with walking off the end of the stack if it doesn't... I also added a test for some of these behaviors. Differential Revision: https://reviews.llvm.org/D150236