STM32CubeProgrammer 2.20.0 crash in libCubeProgrammer_API.so

[grevaillot]

Hello,

I'm experiencing some hard unstabilities navigating in stm32cubeprogrammer 2.20.0 UI on an up to date debian trixie system. Even without being connected to programmer, attempting to start tool in production programming mode frequently leads to crash, making tool unreliable. Once programming starts and no UI interaction is done, tool keeps running, but attempt to start/stop usually lead to crash.

Command line programming tool without any issue on that system.

We're using stlink v3mods module with up to date firmware - that project is based on stm32f412re but issue occurs even without mcu connected.

$ /home/xyz/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32CubeProgrammer

Loading PRG Library: /home/xyz/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/../lib/libCubeProgrammer_API.so

[Analytics] No requests are done with CLI
100 external Loader list

Server certificate verification succeed
Server certificate verification succeed
Server certificate verification succeed
Server certificate verification succeed
Server certificate verification succeed
Server certificate verification succeed
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f9152257635, pid=2108007, tid=0x00007f91683816c0
#
# JRE version: OpenJDK Runtime Environment (8.0_432-b07) (build 1.8.0_432-b07)
# Java VM: OpenJDK 64-Bit Server VM (25.432-b07 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libCubeProgrammer_API.so+0x257635] FlashLoaderMng::initElfLoaderParameters(bool, char*)+0x205
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/xyz/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/hs_err_pid2108007.log
#
# If you would like to submit a bug report, please visit:
# https://bell-sw.com/support
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
/home/xyz/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32CubeProgrammer: line 5: 2108007 Aborted GDK_BACKEND=x11 "$DIR"/jre/bin/java -Djdk.gtk.version=2 -jar "$DIR/STM32CubeProgrammerLauncher" 2> /dev/null

[Ozone]

To be honest, Linux support for ST's development tools (CubeIDE and programmer) is quite weak.
Not sure if they tested your distribution (and version) - it seems not.

> # SIGSEGV (0xb) at pc=0x00007f9152257635, pid=2108007, tid=0x00007f91683816c0

That could not have slipped through otherwise.

You can try switching Java environments, other (older distros), or older versions of the Cube Programmer.
And if you are curious, you could try running it in a tool like valgrind.

OpenOCD on Linux supports the ST-Link as well, if this is an alternative.

[grevaillot]

i've been experiencing these issues with java 21, migration to 25 did not help - and crash occurs in native lib, so i wasnt really expecting improvement :) - i did some tracing with gdb but it did not provide additional useful tips.

Indeed, some opensource tools under Linux are much more supported, but stm32cubeprogrammer, and specifically factory programming mode is punctually used here by operators to update relatively considerable batches (~100+) of products and was quite efficient at that job.. we might bite the bullet and write a proper tool based on the lib, or buy more Segger flasher for that job, but this used to work and was cheap, so this is a bit sad.

[Ozone]

> ... we might bite the bullet and write a proper tool based on the lib, or buy more Segger flasher for that job, but this used to work and was cheap, so this is a bit sad.

On a related note, I have converted most of my discovery & nucleo board ST-Links to JLinks, with the firmware available from Segger's website. This process is relatively painless and reversible, although the licence conditions prohibit uses other than for the on-board target. Which is fine for me.
I very much dislike Cube / HAL (for technical and quality reasons), and Eclipse in general.
Using Segger's Embedded Studio (for private purposes), the conversion was the logical choice.

For commercial use in my company, CubeIDE is out of the question for production use.
Not only do we need to support several different architectures for the same firmware, but our CI system practically excludes IDEs. The build process is thus fully based upon make files - still requiring a target-specific toolchain.

And since most of our products are also produced in ~10's to ~1000's, a proper flash programming adapter (again Segger) is well justified.