GDB Server fails to start

[MHast.1]

Hello, I have a problem running any project in STM32CubeIDE v1.7.0

When I press 'Run' I usually get "Launching: Performing pre-launch check..." and it just hangs there.

Sometimes it gets past that, and then I get the following error

Error in final launch sequence: Failed to execute MI command: target remote localhost:61234

Error message from debugger back end: localhost:61234: The system tried to join a drive to a directory on a joined drive.

at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:1014) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:843)

Console output:

STMicroelectronics ST-LINK GDB server. Version 5.9.1

Copyright (c) 2021, STMicroelectronics. All rights reserved.

Starting server with the following options:

    Persistent Mode      : Disabled

    Logging Level       : 1

    Listen Port Number     : 61234

    Status Refresh Delay    : 15s

    Verbose Mode        : Disabled

    SWD Debug         : Enabled

    InitWhile         : Enabled

Waiting for debugger connection...

[MHast.1]

It happens on any project on this machine, regardless of configuration (release, debug). I have another machine with v1.7.0 installed and I can run all the same projects without issues.

I have no problem using STM32Programmer and connecting to ST-Link.

Using Windows 10, P-NUCLEO-WB55 board.

[MHast.1]

Problem doesn't happen with STM32CubeIDE v1.6.1 (ST-LINK GDB server v5.8.0). So it's an issue from the latest release.

[mattias norlander]

Some follow-up questions...

Q1: What happens if you switch to a new workspace with a new project? Same problem then?

Q1a: If not, what happens if you import your old projects into a new workspace?

Q2: But if you just click build the project builds successfully?

Q3: What happens if you go into the debug configuration and click "disable auto build"?

Q4: Do you have any anti-virus firewall running that may be blocking any debug relates service from running? Maybe worth to try to quickly disable or examine related logs...

[MHast.1]

Hello, thanks for your response

Q1 - Yes, same problem. I've tried new workspaces, removing and reinstalling everything, different launch configs.

Q2 - Yes, no issues with builds, the problem is running it

Q3 - Same issue

Q4 - I checked Windows firewall settings, both stm32cubeide and st-link_gdbserver were allowed access

The main thing is that it happens with IDE v1.7.0 and not v1.6.1. I'm using Windows 10, nothing special with the setup, I use some drive letters mapped with SUBST.

[mattias norlander]

Well the GDB-server seem to start just fine. It is waiting for the GDB-client to connect to it. So this part seem to work well.

But it seems like the GDB-client is not permitted to *** through on the port.

Q5: Maybe you can do as @JFeut.1​ proposed below and change the port to see if that is for some reason blocked?

Q6: Since things work in CubeIDE 1.6 but not in 1.7, then we need to understand if the is the GDB-server or the GDB-client in 1.7 which is the root-cause. Maybe you can try this by mixing the tools like this:

• Launch the GDB-server from 1.7 externally via command-line terminal. Hint: You can copy the full launch parameters from the debug config by clicking "show command line". Now launch CubeIDE 1.6 and setup a debug config which remote connects to the externally launched GDB-server from the 1.7 package.
  • If it fails, there is some issue with the 1.7 GDB-server on your system.
• Next. Try the opposite. Launch GDB-server from 1.6 and launch remote debug from CubeIDE 1.7.
  • If it fails then there is some issue with CubeIDE or the GDB-client on your system.

Alternatively you could try in the CubeIDE 1.7 to launch a debug session relying on OpenOCD instead of ST-LINK GDB-server. That could also hint about whether client or server is the issue?!

I think this issue is quite specific to your (and maybe a few other's) environments. My best bet is still AV/firewall configurations. Let's see what your tests indicates..

[Bgrth.1]

Yes its the same issue that I am facing in my GDB server its not starting like an ideal server you can see here this guys is mentioning the same issue that I am facing in my server please help us to solve this issue.

[mattias norlander]

Hard to help since we cannot re-produce the issue. We have to rely on you guys trying our suggestions and provide feedback on if any of the suggestions work or not.

So, please go through the suggestion questions/suggestions above, try them and provide answers to if any of them seem to help...

[JFeut.1]

I have done a video to fix the issue : Failure starting GDB server - YouTube

the video is in french, but simply just change the TCP port 61234 to anything else and it has solved my problem

[PFirt.1]

I had the same issue with CubeIDE v1.7.0 and this also worked for me. Thnaks

[Slove.1]

One other (maybe obscure) reason that leads to very similar symptoms (namely the hanging of the start of the debugging process) is that STM32cubeIDE does not use an absolute path of stlink-server. I have an alias in my PATH named stlink-server that points to st-util of https://github.com/texane/stlink.

Once querying PATH leads to the stlink-server binary installed with the IDE everything works fine. Maybe something similar happens with multiple versions of the IDE installed too.

[PHolt.1]

This is just a common issue which happens randomly. With a bit of luck, not often. I find it happens more often when running Cube over RDP (remote desktop). Often the solution is to unplug/replug the USB cable into STLINK, close Cube, and terminate the ST process in Windows Task Manager, which is a hassle because you can't unplug the USB cable remotely : - )

[JBern.7]

Well ... It is 2022 now, perhaps I am late. But just in case someone has the same question and tried removing/changing the USB as suggested in the previous comment, it did not work. So, my board only started to behave in such a manner after I turned on the FreeRTOS and changed the Serial wire to the Trace function. So cut long story short. I used STM32CubeProgrammer and cleared the full chip and upgraded the firmware, after this everything works perfectly.

[iforce2d]

Just find the gdb process that is using the port in question and kill it. Eg. in my case on Linux I do this:

killall ST-LINK_gdbserver

You can likely find the process by doing:

ps -aux | grep gdb

As to why this problem happens or how to prevent it in future, I have no clue.