summaryrefslogtreecommitdiff
path: root/lldb/test/API/functionalities/scripted_process/TestStackCoreScriptedProcess.py
AgeCommit message (Collapse)Author
2025-02-23Allow option to ignore module load errors in ScriptedProcess (#127153)rchamala
Current state in scripted process expects [all the modules](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L498) passed into "get_loaded_images" to load successfully else none of them load. Even if a module loads fine, [but has already been appended](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L495) it still fails. This is restrictive and does not help our usecase. **Usecase**: We have a parent scripted process using coredump + tombstone. 1) Scripted process uses child elf-core process to read memory dump 2) Uses tombstones to pass thread names and modules. We do not know whether the modules will be successfully downloaded before creating the scripted process. We use [python module callbacks](https://github.com/llvm/llvm-project/blob/a57e58dbfaae0e86eb5cafeddf8b598f14b96e36/lldb/source/Target/Platform.cpp#L1593) to download a module from symbol server at LLDB load time when the scripted process is being created. The issue is that if one of the symbol is not found from the list specified in tombstone, none of the modules load in scripted process. Even if we ensure symbols are present in symbol server before creating the scripted process, if the load address is wrong or if the module is already appended, all module loads are skipped. **Solution**: Pass in a custom boolean option arg for every module from python scripted process plugin which will indicate whether to ignore the module load error. This will provide the flexibility to user for loading the successfully fetched modules into target while ignoring the failed ones --------- Co-authored-by: rchamala <rachamal@fb.com>
2025-02-06[lldb][NFC] Remove old skipIfOutOfTreeDebugserver's (#126144)Jason Molenda
When a test depends on a new debugserver feature/fix, the API test must be marked @skipIfOutOfTreeDebugserver because the macOS CI bots test using the latest Xcode release debugserver. But over time all of these fixes & new features are picked up in the Xcode debugserver and these skips can be removed. We may see unexpected test failures from removing all of these 1+ year old skips, but that's likely a separate reason the test is failing that is being papered over by this skip.
2023-06-21[lldb/test] Disable TestStackCoreScriptedProcess.pyMed Ismail Bennani
This patch disables TestStackCoreScriptedProcess.py since it times out non deterministicly. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2023-06-21[lldb] Fix failure in TestStackCoreScriptedProcess on x86_64Med Ismail Bennani
This patch should address the failure of TestStackCoreScriptedProcess that is happening specifically on x86_64. It turns out that in 1370a1cb5b97, I changed the way we extract integers from a `StructuredData::Dictionary` and in order to get a stop info from the scripted process, we call a method that returns a `SBStructuredData` containing the stop reason data. TestStackCoreScriptedProcess` was failing specifically on x86_64 because the stop info dictionary contains the signal number, that the `Scripted Thread` was trying to extract as a signed integer where it was actually parsed as an unsigned integer. That caused `GetValueForKeyAsInteger` to return the default value parameter, `LLDB_INVALID_SIGNAL_NUMBER`. This patch address the issue by extracting the signal number with the appropriate type and re-enables the test. Differential Revision: https://reviews.llvm.org/D152848 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2023-06-13Revert "[lldb] Fix failure in TestStackCoreScriptedProcess on x86_64"Med Ismail Bennani
This reverts commit 4177b490358432a457935ba5d6d076ae60de588f, since I landed it by mistake.
2023-06-13[lldb] Fix failure in TestStackCoreScriptedProcess on x86_64Med Ismail Bennani
This patch should address the failure of TestStackCoreScriptedProcess that is happening specifically on x86_64. It turns out that in 1370a1cb5b97, I changed the way we extract integers from a `StructuredData::Dictionary` and in order to get a stop info from the scripted process, we call a method that returns a `SBStructuredData` containing the stop reason data. TestStackCoreScriptedProcess` was failing specifically on x86_64 because the stop info dictionary contains the signal number, that the `Scripted Thread` was trying to extract as a signed integer where it was actually parsed as an unsigned integer. That caused `GetValueForKeyAsInteger` to return the default value parameter, `LLDB_INVALID_SIGNAL_NUMBER`. This patch address the issue by extracting the signal number with the appropriate type and re-enables the test. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2023-05-25TestStackCoreScriptedProcess.py is timing out, skip itJason Molenda
The x86_64 macOS CI bot is failing because this test times out. It was marked as expectedFail earlier today, but that's not considered a fail so the CI runs are red. Skipping it on Darwin for now until Ismail can look into it.
2023-05-25Re-revert "[lldb] Move PassthroughScriptedProcess to `lldb.scripted_process` ↵Med Ismail Bennani
module" This reverts commit 429e74839506ea8ba962d24647264ed81f680bbf since it didn't address the test failures on GreenDragon. This patch will mark the tests as expected to fail until I can reproduce the issue and find a solution. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
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-01-30[lldb/test] Skip TestStackCoreScriptedProcess if Asan is enabledMed Ismail Bennani
This patch skips TestStackCoreScriptedProcess because the test times out when the Address Sanitizer is running. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2023-01-12[lldb/test] Fix data racing issue in TestStackCoreScriptedProcessMed Ismail Bennani
This patch should fix an nondeterministic error in TestStackCoreScriptedProcess. In order to test both the multithreading capability and shared library loading in Scripted Processes, the test would create multiple threads that would take the same variable as a reference. The first thread would alter the value and the second thread would monitor the value until it gets altered. This assumed a certain ordering regarding the `std::thread` spawning, however the ordering was not always guaranteed at runtime. To fix that, the test now makes use of a `std::condition_variable` shared between the each thread. On the former, it will notify the other thread when the variable gets initialized or updated and on the latter, it will wait until the variable it receives a new notification. This should fix the data racing issue while preserving the testing coverage. rdar://98678134 Differential Revision: https://reviews.llvm.org/D139484 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-10-27[lldb][test] Remove empty setUp/tearDown methods (NFC)Dave Lee
2022-06-17[lldb][tests] Automatically call compute_mydir (NFC)Dave Lee
Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py. Differential Revision: https://reviews.llvm.org/D128077
2022-04-08[lldb] Skip more tests that don't make sense to run remotelyJonas Devlieghere
Skip another batch of tests that don't really make sense to run remotely.
2022-03-04[lldb/Test] Fix test_launch_scripted_process_stack_frames failureMed Ismail Bennani
This should fix the test_launch_scripted_process_stack_frames GreenDragon test failure : https://green.lab.llvm.org/green/job/lldb-cmake/41901 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-03-04[lldb/Plugins] Add ability to load modules to Scripted ProcessesMed Ismail Bennani
This patch introduces a new way to load modules programatically with Scripted Processes. To do so, the scripted process blueprint holds a list of dictionary describing the modules to load, which their path or uuid, load address and eventually a slide offset. LLDB will fetch that list after launching the ScriptedProcess, and iterate over each entry to create the module that will be loaded in the Scripted Process' target. The patch also refactors the StackCoreScriptedProcess test to stop inside the `libbaz` module and make sure it's loaded correctly and that we can fetch some variables from it. rdar://74520238 Differential Revision: https://reviews.llvm.org/D120969 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-02-14[lldb] Replace asserts on .Success() with assertSuccess()Dave Lee
Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759). * `assertSuccess` prints out the error's message * `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output * `assertSuccess` seems not to be well known, using it where possible will help spread knowledge * `assertSuccess` statements are more succinct Differential Revision: https://reviews.llvm.org/D119616
2022-02-09[lldb/test] Split Scripted Process test in multiple tests (NFC)Med Ismail Bennani
This splits the scripted process tests to be able to run in parallel since some of test functions can take a very long time to run. This also disables debug info testing. Differential Revision: https://reviews.llvm.org/D118513 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>