Error trying to launch STM32CubeIDE on linux!

[RBamf.1]

I have installed the STM32CubeIDE 1.12.0 from the STM32 official website onto my Arch Linux laptop but when i try to launch it, it closes and reports an error after the splash screen.

I have searched on pacman (the arch package manager) for stm32cubeide too, but they are having the same error too. See the comments section on https://aur.archlinux.org/packages/stm32cubeide

Here is the error:

[ri@r Desktop]$ /opt/st/stm32cubeide_1.12.0/stm32cubeide_wayland
SWT WebKitGDBus: error creating DBus server Error binding to address (GUnixSocketAddress): No such file or directory
SWT WebKit: error initializing DBus server, dBusServer == 0
 
(STM32CubeIDE:9473): GLib-GIO-CRITICAL **: 16:40:15.499: g_dbus_server_get_client_address: assertion 'G_IS_DBUS_SERVER (server)' failed
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fd88683ed16, pid=9473, tid=9474
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.17+8 (11.0.17+8) (build 11.0.17+8)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.17+8 (11.0.17+8, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  [libswt-gtk-4950r5.so+0x3ed16]  Java_org_eclipse_swt_internal_C_strlen+0xf
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /home/richard/Desktop/core.9473)
#
# An error report file with more information is saved as:
# /home/r/Desktop/hs_err_pid9473.log
Compiled method (nm)    9481 5616     n 0       org.eclipse.swt.internal.C::strlen (native)
 total in heap  [0x00007fd917d3c190,0x00007fd917d3c530] = 928
 relocation     [0x00007fd917d3c308,0x00007fd917d3c338] = 48
 main code      [0x00007fd917d3c340,0x00007fd917d3c528] = 488
 oops           [0x00007fd917d3c528,0x00007fd917d3c530] = 8
Compiled method (nm)    9486 5616     n 0       org.eclipse.swt.internal.C::strlen (native)
 total in heap  [0x00007fd917d3c190,0x00007fd917d3c530] = 928
 relocation     [0x00007fd917d3c308,0x00007fd917d3c338] = 48
 main code      [0x00007fd917d3c340,0x00007fd917d3c528] = 488
 oops           [0x00007fd917d3c528,0x00007fd917d3c530] = 8
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

And the error report file is attached below.

[KSchr.3]

I'm following this issue due to the reason that I don't want to run in such circumstances. So I've looked to the official documents what ST promises regarding running STM32CubeIDE. In the Release notes RN0114 (Rev 21) is written that STM32CubeIDE was tested with the Linux distributions Ubuntu 20.04 LTS and Fedora 31. Fedora 31 was released end of October 2019 so it's slightly outdated. Currently Fedora 37/38beta are the latest releases. Ubuntu 20.04 was first released in April 2020 and gets several updates in the meantime. It's obviously that people run into problems like crashes when they install STM32CubeIDE on a newer distribution. The reason for that could be, as mentioned by others, the newer glibc library. However, it would be nice if ST would like to test STM32CubeIDE with more recent distributions.

@RBamf.1​ : You didn't provide any information about your distribution with which you experienced this issue. In your hs_err_pid9473.log file there's only shown that you're using EndeavourOS but without any release number.

[AScha.3]

and for me (i installed my actual MX Linux 2018 ) :

However, it would be nice if ST would like to test STM32CubeIDE with older distributions also.

the same problem: libc.so.6: version `GLIBC_2.27' not found . if your system is older or new - same problem.

so it would be better, to get rid of this query on exact a certain version of this lib; other progs, browsers etc can do this obviously very well.

workaround for me was: changing the GNU Tools version ( from Julien D (ST Employee) ) ->

 try to install back the GNU Tools for STM32 7-2018-q2-update toolchain from the Preferences > STM32Cube > Toolchain Manager page and set it as Default

[Markus GIRDLAND]

The problem in this case seems to be, like @KSchr.3​ mentions, the newer Linux distribution.

The key revealing lines of the error log is from the THREAD section that says:

C  [libswt-gtk-4950r5.so+0x3ed16]  Java_org_eclipse_swt_internal_C_strlen+0xf
j  org.eclipse.swt.internal.Converter.cCharPtrToJavaString(JZ)Ljava/lang/String;+1
j  org.eclipse.swt.browser.WebKit$WebKitExtension.initializeWebExtensions_callback(JJ)V+178

Something about the webkit native to the OS is incompatible with what STM32CubeIDE uses which stems from the fact that it's a non-supported Linux version.

I agree that we should be testing on newer Linux distributions but it was not prioritized for this release.

[RBamf.1]

Hi, the version on flatpak works on the newer distribution, https://flathub.org/apps/details/com.st.STM32CubeIDE

[lesmalave]

The version of the STM32CUBEIDE of Flatpak is old.

Personally, I have been using STM32cubeide on ArchLinux for a couple of years and I have never had a problem until now.

I have tried the suggested solutions in AUR with no positive result, either on X11 or on Wayland.

I really hope a quick solution to this problem that is occurring in different Linux Distros.

[squiggle]

I am having a similar problem on Ubuntu 20.04 except without an error message. But it freezes on the splash screen and never recovers.

[KSchr.3]

If someone is using Arch and don't need the latest version of STM32CubeIDE as I do (I'm still using ver. 1.11.0), it could be a solution to prevent STM32CubeIDE to be automatically updated by pamac/paru/yay/.... by adding a line to /etc/pacman.conf:

IgnorePkg  = stm32cubeide

It's also possibly to roll back to version 1.11.0 until this issue has been fixed.

[squiggle]

Update: using 1.11.0 instead of 1.12.0 fixed the problem.

[Alex the Peasant]

Yeah I'm using Arch but I'd prefer to use the latest version of the Cube IDE.

I'm probably just gonna fire up a docker ubuntu container and run it in that.

It's things like this the reason that Linux never really took over the desktop, you upgrade or downgrade glibc and *everything* breaks.