DWARF2 Queue Guard Internal Error on run

[christiankissig]

DWARF2 Queue Guard Internal Error on run

[sakhnik]

Thanks for reporting. It'll take some time and effort to investigate.

[sakhnik]

@christiankissig, I was able to reproduce the issue with your instructions. And gdb doesn't crash anymore for me after the fix, although in x64. Could you please verify the bug has been fixed in your environment?

[christiankissig]

Thank you for the quick fix @sakhnik . The issue is fixed, but I'm seeing another issue

    1 Reading symbols from /home/ubuntu/workspace/llvm-project/build/unittests/CodeGen/./CodeGenTests...
    2 (gdb) break KnownBits.cpp:90
    3 Breakpoint 1 at 0x442c2ae: file /home/ubuntu/workspace/llvm-project/llvm/lib/Support/KnownBits.cpp, line 90.
    4 (gdb) run
    5 Starting program: /home/ubuntu/workspace/llvm-project/build/unittests/CodeGen/CodeGenTests --gtest_filter=AArc
    6 h64SelectionDAGTest.ComputeKnownBits_USUBO_CARRY
    7 /build/gdb-ZgDh0V/gdb-12.1/gdb/frame.c:3052: internal-error: frame_cleanup_after_sniffer: Assertion `frame->pr
    8 ologue_cache == NULL' failed.
    9 A problem internal to GDB has been detected,
   10 further debugging may prove unreliable.
   11 ----- Backtrace -----
   12 0x55bcb330c077 ???
   13 0x55bcb3670a64 ???
...
   38 0x7f607801758a ???
   39 0x7f6077294b42 start_thread
   40         ./nptl/pthread_create.c:442
   41 0x7f60773269ff ???
   42         ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
   43 0xffffffffffffffff ???
   44 ---------------------
   45
   46 This is a bug, please report it.  For instructions, see:
   47 <https://www.gnu.org/software/gdb/bugs/>.

I seem to have above commit

 ubuntu@ip-172-31-16-55  ~/.local/share/nvim/site/pack/packer/start/nvim-gdb   master  git log --pretty=oneline 
69d055aad50adb80a5f0b1ddeeef05dce92871c2 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'devel'
302f075756b7bbdb6cd291f72a29375cf79a5d04 (origin/devel) Merge branch 'lua' into devel
12c04360779a6b552e8616523a3425e0a3706514 (origin/lua) Try disabling failing test: fails only in GH actions
78bf4dfa68b5995e8037dca7e3371aaaa1ad6747 Fix #201: track the state of the inferior with events
5b5dc35f58324256dc62285c77c43353866606e7 Update spy_ui to the latest protocol
428552fd5e47623c268bc150357be126bf82295c (grafted) Fix typo
6fd4eb53ac25fda0c2f1a60457c5f0592a0e95ad (grafted) Merge branch 'devel'
993e43e8e3dced7915bf9be97065da5464daef63 (grafted) Fix #198 use socket.exception appropriately

From console this GDB works fine

 ubuntu@ip-172-31-16-55  ~/workspace/llvm-project   main ● ?  gdb -q --args /home/ubuntu/workspace/llvm-project/build/unittests/CodeGen/CodeGenTests --gtest_filter=AArch64SelectionDAGTest.ComputeKnownBits_UADDO_CARRY
Reading symbols from /home/ubuntu/workspace/llvm-project/build/unittests/CodeGen/CodeGenTests...
(gdb) break KnownBits.cpp:90
Breakpoint 1 at 0x442c2ae: file /home/ubuntu/workspace/llvm-project/llvm/lib/Support/KnownBits.cpp, line 90.
(gdb) run
Starting program: /home/ubuntu/workspace/llvm-project/build/unittests/CodeGen/CodeGenTests --gtest_filter=AArch64SelectionDAGTest.ComputeKnownBits_UADDO_CARRY
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Note: Google Test filter = AArch64SelectionDAGTest.ComputeKnownBits_UADDO_CARRY
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from AArch64SelectionDAGTest
[ RUN      ] AArch64SelectionDAGTest.ComputeKnownBits_UADDO_CARRY
[       OK ] AArch64SelectionDAGTest.ComputeKnownBits_UADDO_CARRY (40 ms)
[----------] 1 test from AArch64SelectionDAGTest (40 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (41 ms total)
[  PASSED  ] 1 test.
[Inferior 1 (process 28317) exited normally]
(gdb)

Do you want me to open another issue?

[christiankissig]

Btw this not running on aarch64, just a cross-compile scenario being tested:

> uname -m
x86_64

[sakhnik]

I'm reopening the same ticket. It looks like the issue is more severe than I anticipated. A python script is run inside gdb to fetch information about the current line and breakpoints: https://github.com/sakhnik/nvim-gdb/blob/master/lib/gdb_commands.py . And because a separate thread is forked to handle external commands, I can easily imagine how different kinds of data races can occur.
So let me take a closer look at gdb.

I'm not able to reproduce the issue this time. How do you build llvm?

[christiankissig]

I'm sorry @sakhnik , I've missed this message in my inbox.

Thanks for the deep dive! I'm building LLVM as follows

❯ cmake -S llvm -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug
❯ ninja -C build