Jlink locks up eclipse

[trampas]

I have noticed for several years now that when using eclipse with JLink GDB server that eclipse will often lock up. I found that I can replicate the issue by doing the following.

1. build and embedded project in debug mode
2. Program the code and start debugging using eclipse
3. Power off the embedded target.

This will cause the eclipse to stop responding and eclipse GUI becomes grayed out. If I leave it like this for 30 mins it may recover and may not. I found that when this happens I have to go in task manager and kill JLinkGCBServerCLI.exe, JLinkGUIServer.exe and Eclipse.exe and then restart eclipse.

I am currently on the 2024-09 build of eclipse, but I have noticed this behavior for years, like 5+.

I have been told this is a JLink issue and not eclipse, but I have found that other IDEs, like VSCode, Keil, Segger Embedded Studio, and others do not have this problem.

I suspect that JLink GDB server is sending a notification that something happened and eclipse wrapper is not processing it. Maybe there is some timeout in the JLink wrapper that is set too high, etc. Either way this problem is very annoying.

Note the above steps can replicate the problem, but I have also notice this can randomly happen. Here is an example where eclipse popup error message before the crash. Also note the funny characters on the Jlink terminal before crash.

Any help in resolving this would be appreciated.

[jld01]

Hi @trampas, is there anything in the Eclipse log (Window > Show View > Other... > Error Log) that relates to the internal error?

[trampas]

[trampas]

Here is an export of the log if it helps.
eclipse_log.log

[trampas]

So it appears just building project and loading for debug creates the following log.
eclipse_build_debug.log

[trampas]

I just had it happen again. Eclipse has been locked up for about 15 mins.

[trampas]

[trampas]

eclipse_error.log

Here is the log file.

[jonahgraham]

@trampas the CDT project doesn't launch JLink in this use case, that is handled by our sister project the embed-cdt project. It may be worth posting this to https://github.com/eclipse-embed-cdt/eclipse-plugins/discussions as some of the active embed-cdt folk are not active in this project too.

[SnowyTulip]

@trampas Your description is very detailed—thanks. This has been incredibly helpful for me in troubleshooting this bug.

I have been aware of this issue for quite some time. In fact, I reproduced your problem a few months ago and conducted a thorough investigation into this abnormal behavior. The issue appears to be caused by the J-Link semihosting terminal. I recommend that you try disabling the semihosting terminal first to verify whether the bug still persists.

[SnowyTulip]

I have provided some steps on how I reproduced this issue in Eclipse Embedded CDT:
https://github.com/eclipse-embed-cdt/eclipse-plugins/issues/619#issuecomment-2526296759
（It's strange, why can't you just jump to this link? Please copy it into the browser.）

[SnowyTulip]

Let me analyze the root cause of this issue in more detail.

First, I created a new project following your configuration and conducted debugging using my STM32F4-VE development board with J-Link. However, my reproduction steps were slightly different from what you described. After starting the debug session, if I disconnected the power supply, Eclipse did not freeze. However, when I disconnected the J-Link USB cable during debugging, the issue occurred.

Just as you described, I observed the same Eclipse log, the same Eclipse freeze, and the same strange characters in the terminal console.

Next, I attempted to analyze this abnormal behavior. I traced the source code of Eclipse Embedded CDT and gained an understanding of the J-Link debugging implementation. Unfortunately, when Eclipse froze, there were no J-Link-related exceptions reported in the debugging components.

To investigate further, I reproduced this issue multiple times. At one point, I suddenly realized that Eclipse was not completely frozen—it had just become extremely slow. Reviewing the eclipse_log.log I noticed the message:

org.eclipse.swt.SWTError: No more handles

This made me wonder whether the issue was caused by excessive resource consumption in Eclipse rather than the UI thread being blocked by some unusual Eclipse function.

Additionally, I observed the strange characters being printed uncontrollably in the terminal console. Perhaps this continuous, excessive output was consuming a significant amount of Eclipse SWT resources, ultimately leading to the freeze.
(Only those characters that are not parsed will consume a lot of eclipse swt handle.)

[SnowyTulip]

The terminal that is printing these strange characters uncontrollably is the J-Link semihosting terminal. As far as I know, this tool is designed to conveniently receive output from the chip’s printf() function—eliminating the need for serial output redirection. By using semihosting, you can directly view the printed values.

Its working process is roughly as follows:

Semihosting is a process launched by Eclipse when debugging a J-Link program. It communicates with the J-Link server via TCP and has a dedicated console that prints all data returned by J-Link, as shown in the example below.

Through my testing, I modified the Eclipse Embedded CDT source code and debug it for further analysis and also attempted to use a Python script to read the semihosting output. I discovered that when the J-Link connection is forcibly disconnected, the script receives a large number of unrecognizable characters. In Eclipse, these characters appear as a massive stream of ? symbols, which ultimately leads to the Eclipse freeze.

[SnowyTulip]

Other Tests

You mentioned other IDEs such as VS Code, Keil, and Segger Embedded Studio. I attempted to reproduce the issue, but due to time constraints, I was only able to test Keil and Segger Embedded Studio.

Keil

I couldn't find semihosting support in Keil, so disconnecting the debugger did not cause any issues.

Segger Embedded Studio

For Segger Embedded Studio, I used Wireshark to capture network packets and found that it does not follow the same logic as Eclipse Embedded CDT. In fact, it does not connect to port 2333 at all. Instead, it uses a different TCP-based protocol to implement semihosting, which prevents the issue from occurring.
Additionally, I noticed that pyOCD in Eclipse Embedded CDT also supports semihosting, so I conducted further testing.

PyOCD

Unlike J-Link’s semihosting behavior, pyOCD does not send any messages after a forced disconnection. As a result, it does not cause any issues in Eclipse.

[SnowyTulip]

Solutions

Actually, as the issue suggests, this can be confirmed as a J-Link bug. I haven't made any modifications so far because I haven't determined the best solution. Here are some of my thoughts:

1、Character replacement – Replace undecodable characters with visible '?' symbols. (The challenge is that this requires replacing characters according to the user's encoding settings in Eclipse, and it may introduce unintended side effects.)
2、Monitor J-Link disconnection messages – Detect when J-Link sends a "target lost" message, then terminate the semihosting process and report that it was interrupted.
3、Limit semihosting console output consumption – Implement throttling mechanisms, such as adding delays or monitoring resource usage.
4、Request an official fix from Segger – Ask J-Link's developers to stop sending undecodable characters to the semihosting port when the target is lost.
Each of these approaches has its own drawbacks.

From the IDE’s perspective, I personally prefer a "protection" strategy. I believe that we should not be responsible for J-Link’s bug and should avoid implementing additional monitoring mechanisms like option 2 (listening for "target lost" and terminating the semihosting process). Instead, we should ensure that Eclipse functions correctly when J-Link is working properly. Even if J-Link behaves abnormally (e.g., flooding the console with irrelevant bytes), Eclipse IDE itself should remain stable (without freezing the UI) and report exceptions to the user as clearly as possible.

Therefore, I lean towards option 3, which limits the semihosting process’s output rate to protect Eclipse.And it is also necessary to report this jlink bug to Segger.

I'm not sure if this is the good solution, as I don't have experience dealing with this type of issue. I would need guidance from experienced Eclipse CDT developers. Do you have any better suggestions? @jonahgraham

[trampas]

Maybe a fix would be to use the TCP protocol like Seggeer Embedded Studio? Trampas

…

On Thu, Mar 20, 2025 at 11:14 PM gaobopi ***@***.***> wrote: Solutions Actually, as the issue suggests, this can be confirmed as a *J-Link bug*. I haven't made any modifications so far because I haven't determined the best solution. Here are some of my thoughts: 1、Character replacement – Replace undecodable characters with visible '?' symbols. (The challenge is that this requires replacing characters according to the user's encoding settings in Eclipse, and it may introduce unintended side effects.) 2、Monitor J-Link disconnection messages – Detect when J-Link sends a "target lost" message, then terminate the semihosting process and report that it was interrupted. 3、Limit semihosting console output consumption – Implement throttling mechanisms, such as adding delays or monitoring resource usage. 4、Request an official fix from Segger – Ask J-Link's developers to stop sending undecodable characters to the semihosting port when the target is lost. Each of these approaches has its own drawbacks. From the IDE’s perspective, I personally prefer a "protection" strategy. I believe that we should not be responsible for J-Link’s bug and should avoid implementing additional monitoring mechanisms like option 2 (listening for "target lost" and terminating the semihosting process). Instead, we should ensure that Eclipse functions correctly when J-Link is working properly. Even if J-Link behaves abnormally (e.g., flooding the console with irrelevant bytes), Eclipse IDE itself should remain stable (without freezing the UI) and report exceptions to the user as clearly as possible. Therefore, I lean towards option 3, which limits the semihosting process’s output rate to protect Eclipse.And it is also necessary to report this jlink bug to Segger. I'm not sure if this is the good solution, as I don't have experience dealing with this type of issue. I would need guidance from experienced Eclipse CDT developers. Do you have any better suggestions? @jonahgraham <https://github.com/jonahgraham> — Reply to this email directly, view it on GitHub <#906 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUHSPI3Z6BOEVM2CSHNEWD2VN7YNAVCNFSM6AAAAABOSFYYD6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJXGIYDMNY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[SnowyTulip]

Yes, it's really a good idea. But it seems that segger studio's semi-host works differently from eclipse embedded. I noticed that segger studio doesn't use the extra port for semi-host. I need to understand how Segger Studio works. This will take some time.