[CI]: Add riscv64 job#6
Merged
Merged
Conversation
yuzibo
added a commit
that referenced
this pull request
May 8, 2026
yuzibo
added a commit
that referenced
this pull request
May 8, 2026
yuzibo
added a commit
that referenced
this pull request
May 9, 2026
yuzibo
added a commit
that referenced
this pull request
May 9, 2026
yuzibo
added a commit
that referenced
this pull request
May 9, 2026
yuzibo
added a commit
that referenced
this pull request
May 9, 2026
zhanghb97
pushed a commit
that referenced
this pull request
May 10, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 10, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 12, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 12, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 12, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 14, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 15, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 16, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 17, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 18, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 19, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 20, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 21, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 22, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 23, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 24, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 29, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 30, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 31, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 1, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 1, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 14, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 16, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 17, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 18, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 19, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 20, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 21, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 21, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 23, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 24, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 25, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 26, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 30, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 1, 2026
…lvm#191275)" (llvm#206816) This reverts commit 0f51760. A test fails with the commit (llvm#191275 (comment)): ``` Traceback (most recent call last): File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 596, in test_python_source_frames self.assertNotIn("0xffffffffffffffff", output.lower()) AssertionError: '0xffffffffffffffff' unexpectedly found in "* thread #2, name = 'a.out', stop reason = breakpoint 1.1\n * frame #0: compute_fibonacci at python_helper.py:7 [synthetic]\n frame #1: process_data at python_helper.py:16 [synthetic]\n frame #2: main at python_helper.py:27 [synthetic]\n frame #3: 0x0000badc2de81358 a.out`thread_func(thread_num=0) at main.cpp:44:13\n frame #4: 0x0000badc2de81f9c a.out`void std::__invoke_impl<void, void (*)(int), int>((null)=__invoke_other @ 0x0000f1555ebae74f, __f=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:61:14\n frame #5: 0x0000badc2de81f18 a.out`std::__invoke_result<void (*)(int), int>::type std::__invoke<void (*)(int), int>(__fn=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:96:14\n frame #6: 0x0000badc2de81ee4 a.out`void std::thread::_invoker<std::tuple<void (*)(int), int>>::_m_invoke<0ul, 1ul>(this=0x0000badc66845eb8, (null)=_index_tuple<0ul, 1ul> @ 0x0000f1555ebae7af) at std_thread.h:259:13\n frame #7: 0x0000badc2de81e98 a.out`std::thread::_invoker<std::tuple<void (*)(int), int>>::operator()(this=0x0000badc66845eb8) at std_thread.h:266:11\n frame #8: 0x0000badc2de81d70 a.out`std::thread::_state_impl<std::thread::_invoker<std::tuple<void (*)(int), int>>>::_m_run(this=0xffffffffffffffff) at std_thread.h:211:13\n frame #9: 0x0000f1555ef029cc libstdc++.so.6`___lldb_unnamed_symbol_d29b0 + 28\n frame #10: 0x0000f1555ec30398 libc.so.6`___lldb_unnamed_symbol_800c0 + 728\n frame #11: 0x0000f1555ec99e9c libc.so.6`___lldb_unnamed_symbol_e9e90 + 12\n" ``` I don't know why this test fails with the PR, but I don't have time to fix it now, so revert it to unblock CI. The backtrace was ``` frame #0: compute_fibonacci at python_helper.py:7 [synthetic] frame #1: process_data at python_helper.py:16 [synthetic] frame #2: main at python_helper.py:27 [synthetic] frame #3: 0x0000badc2de81358 a.out`thread_func(thread_num=0) at main.cpp:44:13 frame #4: 0x0000badc2de81f9c a.out`void std::__invoke_impl<void, void (*)(int), int>((null)=__invoke_other @ 0x0000f1555ebae74f, __f=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:61:14 frame #5: 0x0000badc2de81f18 a.out`std::__invoke_result<void (*)(int), int>::type std::__invoke<void (*)(int), int>(__fn=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:96:14 frame #6: 0x0000badc2de81ee4 a.out`void std::thread::_invoker<std::tuple<void (*)(int), int>>::_m_invoke<0ul, 1ul>(this=0x0000badc66845eb8, (null)=_index_tuple<0ul, 1ul> @ 0x0000f1555ebae7af) at std_thread.h:259:13 frame #7: 0x0000badc2de81e98 a.out`std::thread::_invoker<std::tuple<void (*)(int), int>>::operator()(this=0x0000badc66845eb8) at std_thread.h:266:11 frame #8: 0x0000badc2de81d70 a.out`std::thread::_state_impl<std::thread::_invoker<std::tuple<void (*)(int), int>>>::_m_run(this=0xffffffffffffffff) at std_thread.h:211:13 frame #9: 0x0000f1555ef029cc libstdc++.so.6`___lldb_unnamed_symbol_d29b0 + 28 frame #10: 0x0000f1555ec30398 libc.so.6`___lldb_unnamed_symbol_800c0 + 728 frame #11: 0x0000f1555ec99e9c libc.so.6`___lldb_unnamed_symbol_e9e90 + 12 ``` This contains 0xffffffffffffffff in frame 8.
WuXintong123
pushed a commit
that referenced
this pull request
Jul 1, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 1, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 2, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 3, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 4, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 5, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 6, 2026
A `breakpoint set -P <class>` with an invalid-UTF-8 class name crashes lldb with `EXC_BAD_ACCESS`. The class name is passed through unmodified, so the byte sequence `\xd0p` (an incomplete two-byte UTF-8 sequence) reaches the Python layer: ``` ./bin/lldb -b -o $'breakpoint set -P \xd0p -f main.cpp' ./bin/lldb ... PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ Stack dump: #4 PythonDictionary::GetItem(PythonObject const&) const #6 PythonDictionary::GetItemForKey(PythonObject const&) const #7 PythonObject::ResolveNameWithDictionary(StringRef, PythonDictionary const&) #9 ScriptedPythonInterface::CreatePluginObject<...>(...) ``` `ResolveNameWithDictionary` builds a `PythonString` from the class name and looks it up in the module dictionary. When the name is not valid UTF-8, `PyUnicode_FromStringAndSize` returns `NULL`, so the `PythonString` is left with `m_py_obj == NULL`. `GetItemForKey` forwards that object to `GetItem`, which passed the `NULL` `PyObject *` straight to `PyDict_GetItemWithError`. Debugging the crashing lldb under lldb shows the `NULL` key arriving in `GetItem`: ``` (lldb) break set -n lldb_private::python::PythonDictionary::GetItem (lldb) run --no-use-colors -b -s /tmp/bp_cmds.txt * stop reason = breakpoint 1.1 (lldb) up (lldb) frame variable key.m_py_obj (PyObject *) key.m_py_obj = nullptr ``` Continuing lands on the dereference of that `NULL` inside CPython: ``` (lldb) continue * stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: PyDict_GetItemWithError + 40 -> ldr x8, [x1, #0x8] ``` `x1` holds the key argument, which is `NULL`, so reading the type field at offset `0x8` faults at address `0x8`. `GetItem` already guards against an invalid dictionary (`!IsValid()`); extend that guard to reject an invalid key as well and return `nullDeref()`. `GetItemForKey` consumes the error and returns an empty `PythonObject`, so existing callers such as `ResolveNameWithDictionary` keep working and the breakpoint command now fails cleanly instead of crashing. This was found by `lldb-commandinterpreter-fuzzer`. Adds `PythonDataObjectsTest.TestPythonDictionaryGetItemWithInvalidKey`, which feeds an invalid-UTF-8 key to `GetItem`. Without the fix the test dereferences the `NULL` key and crashes (`SIGSEGV`).
WuXintong123
pushed a commit
that referenced
this pull request
Jul 6, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 8, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 8, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 14, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.