LLDB-DAP: 'Execution errors must have error description'

[Peternj42]

I'm having the same issue as #129 using GoLand on Windows 10. The debug console opens, then closes after a few seconds and gives an IDE error:

Execution errors must have error description

com.intellij.execution.ExecutionException
	at com.lasagnerd.odin.debugger.drivers.dap.DAPDriverUtils.get(DAPDriverUtils.java:187)
	at com.lasagnerd.odin.debugger.drivers.dap.WrappedDebugServer.launchNow(WrappedDebugServer.java:48)
	at com.lasagnerd.odin.debugger.drivers.dap.DAPDriver.loadForLaunch(DAPDriver.java:262)
	at com.jetbrains.cidr.execution.debugger.CidrLocalDebugProcess.doLoadTarget(CidrLocalDebugProcess.java:39)
	at com.jetbrains.cidr.execution.debugger.CidrDebugProcess.lambda$start$8(CidrDebugProcess.java:613)
	at com.jetbrains.cidr.execution.debugger.CidrDebugProcess$VoidDebuggerCommand.call(CidrDebugProcess.java:1257)
	at com.jetbrains.cidr.execution.debugger.CidrDebugProcess$VoidDebuggerCommand.call(CidrDebugProcess.java:1251)
	at com.jetbrains.cidr.execution.debugger.CidrDebuggerCommandExecutor$executeCommand$3.invokeSuspend(CidrDebuggerCommandExecutor.kt:109)
	at com.jetbrains.cidr.execution.debugger.CidrDebuggerCommandExecutor$executeCommand$3.invoke(CidrDebuggerCommandExecutor.kt)
	at com.jetbrains.cidr.execution.debugger.CidrDebuggerCommandExecutor$executeCommand$3.invoke(CidrDebuggerCommandExecutor.kt)
	at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:62)
	at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:163)
	at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)
	at com.jetbrains.cidr.execution.debugger.CidrDebuggerCommandExecutor.executeCommand(CidrDebuggerCommandExecutor.kt:87)
	at com.jetbrains.cidr.execution.debugger.CidrDebuggerCommandExecutor$executeCommandAsync$1.invokeSuspend(CidrDebuggerCommandExecutor.kt:66)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
	at com.intellij.util.concurrency.BoundedTaskExecutor.doRun(BoundedTaskExecutor.java:249)
	at com.intellij.util.concurrency.BoundedTaskExecutor.access$200(BoundedTaskExecutor.java:30)
	at com.intellij.util.concurrency.BoundedTaskExecutor$1.executeFirstTaskAndHelpQueue(BoundedTaskExecutor.java:227)
	at com.intellij.util.ConcurrencyUtil.runUnderThreadName(ConcurrencyUtil.java:218)
	at com.intellij.util.concurrency.BoundedTaskExecutor$1.run(BoundedTaskExecutor.java:212)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:735)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:732)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:732)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.util.concurrent.TimeoutException
	at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1960)
	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2095)
	at com.lasagnerd.odin.debugger.drivers.dap.DAPDriverUtils.get(DAPDriverUtils.java:185)
	... 28 more

I have LLVM 18.1.8 with python 3.10 embedded in the bin folder with lldb-dap.

The windows debugger works for me, but it can't read memory inside slices or maps, making it fairly useless.

[obiwan87]

Can you describe how you try to read slices/maps? Do you rely on the GUI?

[Peternj42]

Yes, using the GUI in GoLand. This is what it looks like with windows debugger:

This seems to be a separate issue with the windows debugger, I get the same results in VSCode. In the Odin discord it looks like people are getting better results with LLDB, but I keep running into the error per my initial post.

[obiwan87]

Ok, got it. I don't know about maps, will do some research on it.

For slices I you can use the following expression:

I'll get back to you regarding maps

[obiwan87]

Note to myself:

For slices, providing a more convenient visualization in the GUI is actually quite trivial. Access the data and len fields of the slice "structure" and iterate over its values. Or, evaluate expression slice.data, slice.len and display its result in the tree.

For maps, it needs to be known how they are actually laid out in memory. Once it is known, all key-value pairs have to be retrieved from there and displayed as a node in the debugger value tree.

[Peternj42]

Evaluate expression isn't working for me (should be a slice of [6]u16):

The program runs correctly, so I know the right data is in there. When you say to iterate over the values, do you mean in the program itself, such that debugger can read each value independently?

[obiwan87]

The previous comment was more of a note to myself on how to implement the stuff in the plugin.

But back to your issue

Evaluate expression isn't working for me (should be a slice of [6]u16):

Are you using windows debugger or lldb-dab in that case? The slice, index works for windows debugger only. I don't know how to achieve the same in lldb-dap tbh.

[Peternj42]

That's with windows debugger. LLDB isn't working for me at all.

[obiwan87]

ok, got ya. I tried to reproduce your issue on my machine, but no luck. :(

Can you please tell me what version of Odin you're using? I will try to reproduce it with the same version you have?

You can just copy-paste whatever odin report spits out

[Peternj42]

    Odin:    dev-2025-01-nightly:2aae4cf
    OS:      Windows 10 Home Basic (version: 22H2), build 19045.5371
    CPU:     Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz
    RAM:     16318 MiB
    Backend: LLVM 18.1.8

[Peternj42]

GoLand version 2024.2.3

[obiwan87]

On maps:

This is by gingerBill, te creator of Odin:

Odin's map implementation is very complicated to be heavily optimized as a general hash map.
It's effectively 3 big tricks in one:

• one giant allocation for everything, where that pointer has to be 64-byte aligned so that we can store its capacity in the lower 6 bits (we mask to get the real pointer)
• SOA based arrays (keys, values, hashes)
• Cell based arrays

The array is split into cells which are the size of a cache line. Each cell contains as many of that element as possible and then pads to the end of the cacheline. This means access into a cell might be a bit more complex to handle due to double layering
I was considering this as a language feature at one point but then realized it's such a rare thing, it's probably not needed at the language level.