Multithread debug issues

[lenfien]

I have just touched vim. My English is not very good, please feel free to laugh at me.
I used lldb.nvim to debug multithreaded code when there was a bug.
First, I use the "thread select" command to select a thread, and then enter the "LL next" command, lldb.nvim will automatically switch to the main thread. I have to choose my target thread over and over again.
After testing, this bug does not appear to use lldb directly.
I captured a video as follows:

[critiqjo]

Wow! Thanks for the rich bug report. Unfortunately, this is probably due to the same reason as #50 (which is that it has nothing to do with this plugin; just bugs within LLDB's python API).

To elaborate a little more, commands executed using :LL are directly processed by a SBCommandInterpreter object. The only extra commands that are executed by the plugin are these for populating the vim buffers with relevant information. Fetching the breakpoints list for placing the bp-signs, and the program counter list for placing the pc-signs all use LLDB's python APIs, and are not supposed to affect the selected thread.

In short, there's nothing I can do! (And I refuse to patch up an upstream bug in plugin either.) The more important issue is that lldb-devs don't seem to care about Python API bugs either (for some years now). I think they are expecting plugins to use their new machine interface which is developed to be compatible with GdbMI which claims to be becoming a de-facto standard (Update: link now broken, but see this project which, in a way, supports this point).

So you might ask: Does this project have no future? That's right, I'm abandoning this project!! 😅 ...in favor of gdb.vim, which uses Gdb/MI through pygdbmi! I'm hoping to resume developing it in a month or two.

PS: What tool did you use for editing the video to add those text bubbles?

[lenfien]

Thank you so much ! The tool is Camtisia 3.
So, It seems the machine interface of lldb and gdb is future. This is the most useful information I get because of my novice.
I am eager to use your new plugin~ Please complete as soon as possible， just can not wait～😊

[johncf]

cc #59

[mellery451]

the link in the README led me here - does this mean that gdb.vim is the way forward even for LLDB users? It unclear to me if it's intended to work using lldb-mi or if it only supports gdb/mi. Any clarification appreciated.

[johncf]

@mellery451 I stopped developing gdb.vim after I met with a roadblock from vim's side at the time (it did not redraw the buffers on windows that are not focused, when the buffers are updated remotely). A gdb.nvim project is definitely very feasible, but currently I'm invested on other projects that I don't have time for it.

[ikcalB]

@lenfien old but gold ;)

what colorscheme do you use in that vid?
Regards from austria

[lanza]

lldb recently had a DAP adapter tool land upstream on master - lldb-vscode. Might be of interest for a tool like this.

[johncf]

@lanza Looks very interesting. I'm sure it'll have long-term support for many debuggers if something as big and popular as VSCode is backing it. Unfortunately, I won't be updating lldb.nvim anymore, nor I would review PRs for this since a large portion of the code needs to be changed and it does not make sense to make radical changes to this project in the absence of an active maintainer.

But you're free to copy any part of the source code (fork or not) if that helps you to create and maintain your own independent project.

[BatmanAoD]

@critiqjo Since the README points to your comment above, would you mind updating the gdb.vim link to point to the current location (under dbgx), since it's currently broken? I suppose you could update the README instead, and I see that you're not actively developing gdb.vim, but at least by editing the comment you'd provide a slightly more robust trail of breadcrumbs than the one I just followed! 😆