avr-gdb with remote target fails with "unknown error" and no logs
I'm running CLion 2026.1.1 on Windows with a pipeline set up for programming AVR chips with avr-gcc. This works well; I can upload binaries and it all works fine.
I am trying to get avr-gdb up and running. I have avarice working fine and if I run avr-gdb on the command line, I can attach to the chip and perform debug operations - so that part works.
In CLion I've set it up as follows;
Where port 4243 is what avarice uses and it works fine when dunning avr-gdb from cli.
When I hit the debug button in CLion, though, all it gives me is this;
No further explanation, no logs, no nothing.
I turned on `com.jetbrains.cidr.execution.debugger` in help > diagnostic tools > debug log settings and was able to get a few entries mentioning avr-gdb, but none of them seem to make much sense;
```
2026-04-26 15:14:06,627 [ 981530] SEVERE - #c.i.e.p.OSProcessHandler - Synchronous execution under ReadAction: D:\dev\tools\avr8-gnu-toolchain-win32_x86_64\bin\avr-gdb.exe --version, see com.intellij.execution.process.OSProcessHandler#checkEdtAndReadAction() Javadoc for resolutions
java.lang.Throwable: Synchronous execution under ReadAction: D:\dev\tools\avr8-gnu-toolchain-win32_x86_64\bin\avr-gdb.exe --version, see com.intellij.execution.process.OSProcessHandler#checkEdtAndReadAction() Javadoc for resolutions
-[x2 of] "component action com.jetbrains.cidr.cpp.toolchains.ui.ToolchainActionItemsComboboxWithBrowseExtension[,0,0,0x0,invalid,layout=com.intellij.ide.ui.laf.darcula.ui.DarculaComboBoxUI$4,alignmentX=0.0,alignmentY=0.0,border=com.intellij.ide.ui.laf.darcula.ui.DarculaComboBoxBorder@4a59dab8,flags=4194664,maximumSize=,minimumSize=,preferredSize=,isEditable=true,lightWeightPopupEnabled=true,maximumRowCount=8,selectedItemReminder=D:\dev\tools\avr8-gnu-toolchain-win32_x86_64\bin\avr-gdb.exe] check version checker: debugger version checker":StandaloneCoroutine{Active}, state: SUSPENDED [ModalityState.ANY, Dispatchers.ui(RELAX).immediate]
at kotlinx.coroutines.flow.StateFlowImpl.collect(StateFlow.kt:411)
at com.intellij.util.ui.ShowingScopeKt$showingScope$3.invokeSuspend(showingScope.kt:125)
```
So the GDB execution freezes the UI or something? I have no idea what to make of this or why it fails.
Any help would be appreciated. This is not a show stopper, but I'd much prefer not having to go back to Atmel Studio for various reasons
Please sign in to leave a comment.
I think you may be using the wrong debug configuration. You've selected the “Remote GDB Server” configuration but you've not provided any gdb server executable, which I suspect is resulting in CLion spinning up the default /usr/bin/gdbserver. With that particular configuration, CLion assumes responsibility for managing the GDB server's (avarice's) process, meaning CLion will automatically start avarice at the beginning of a debug session, and kill it at the end. You've not specified avarice as your GDB server, so CLion may be attempting to start some other GDB server that is not meant to be used in conjunction with AVR targets, resulting in the error you're seeing.
If you're managing avarice's process yourself, then you want the “Remote Debug” configuration:
With the “Remote Debug” configuration, CLion will not assume responsibility for managing the GDB server's process - it leaves that responsibility with the user. Notice the lack of “GDB Server” fields in that debug configuration. Make sure avarice is started and ready for any incoming connections before you start a debug session in CLion.
However, if you **want** CLion to manage avarice for you, then your current configuration is fine, you just need to specify the avarice executable path in the “GDB Server” field, and pass any arguments to avarice via the “GDB Server args” field.
One more thing: keep in mind that CLion is aggressive with its method of killing the GDB server. It may be different on Windows, but on Linux it often kills the server's process with a SIGKILL signal. For programs like avarice, this prevents a proper shut down process to be followed, which could lead to problems with subsequent debug sessions and maybe even program memory corruption (redundant software breakpoints). Something to keep in mind when using CLion to manage avarice's process.
Hope that helps