Can no longer create a new workspace - STM32CubeIDE 1.12.1

[Marcelo Jimenez]

Hi. Since the last update I can no longer create a new workspace.

Any help is appreciated.

OpenSUSE Linux Thumbleweed here.

Best regards,

Marcelo.

.metadata/.ide.log:

2023-04-30 16:42:26,518 [INFO] Activator:176 - 
 
 
2023-04-30 16:42:26,520 [INFO] Activator:177 - !SESSION log4j initialized 
2023-04-30 16:42:26,643 [ERROR] LogOutputStream:75 - [STDERR_REDIRECT] SWT WebKitGDBus: error creating DBus server Error binding to address (GUnixSocketAddress): No such file or directory 
2023-04-30 16:42:26,644 [ERROR] LogOutputStream:75 - [STDERR_REDIRECT] SWT WebKit: error initializing DBus server, dBusServer == 0

[Marcelo Jimenez]

Core dump attached.

[Marcelo Jimenez]

$ /home/mroberto/st/stm32cubeide_1.12.1/stm32cubeide
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:22039): GLib-GIO-CRITICAL **: 00:48:18.989: 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=0x00007f4973c3ed16, pid=22039, tid=22040
#
# 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/mroberto/mrj/xyz/tmp/core.22039)
#
# An error report file with more information is saved as:
# /home/mroberto/mrj/xyz/tmp/hs_err_pid22039.log
Compiled method (nm) 10246 4010 n 0 org.eclipse.swt.internal.C::strlen (native)
 total in heap [0x00007f4a5fcb1590,0x00007f4a5fcb1930] = 928
 relocation [0x00007f4a5fcb1708,0x00007f4a5fcb1738] = 48
 main code [0x00007f4a5fcb1740,0x00007f4a5fcb1928] = 488
 oops [0x00007f4a5fcb1928,0x00007f4a5fcb1930] = 8
Compiled method (nm) 10248 4010 n 0 org.eclipse.swt.internal.C::strlen (native)
 total in heap [0x00007f4a5fcb1590,0x00007f4a5fcb1930] = 928
 relocation [0x00007f4a5fcb1708,0x00007f4a5fcb1738] = 48
 main code [0x00007f4a5fcb1740,0x00007f4a5fcb1928] = 488
 oops [0x00007f4a5fcb1928,0x00007f4a5fcb1930] = 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.
#

Command line info

[Pavel A.]

Looks like run-away strlen call in WebKitGDBus. Change to strnlen.

[Marcelo Jimenez]

Hi Pavel, thanks for your reply.

​

I don't think I have access to the STM32CUBEIDE code, what I have posted is the result of a command line call.

Where are you suggesting me to do this change?

Regards,

Marcelo.

[Semer CHERNI]

Hello @Marcelo Jimenez​ 

First let me thank you for posting.

I am not able to reproduce the described behavior. Maybe our setups are not the same.

Could you provide the Linux version you are working with?

Also I will also need the entire log file and the exact steps which get you to such situation.

KR,

Semer.

[Marcelo Jimenez]

Hi @Semer CHERNI​ ,

Thank you for your answer. I have posted the log file before. Are you refering to a different log file? If so, please specify and I will provide it.

I have also posted the results of running the program from the command line.

All the information about the linux system I am using is in the bottom of the log file I provided before, but I can reproduce any detail you need here if you need. It is an openSUSE Tumbleweed 20230430.

The exact steps are these:

1. Start the STM32CubeIDE. I have started it from the command line so that I could see if there were error messagens. The line I used was "/home/mroberto/st/stm32cubeide_1.12.1/stm32cubeide"
2. When prompted to open a workspace, choose a non-existant workspace to create a new one. I have done this many times before, but it has stopped working.
3. The IDE starts creating the workspace, but crashes in the middle. The .metadata folder is not fully populated.

Regards,

Marcelo.

[flxzt]

I only want to add that I am experiencing the exact same error on Fedora 38 with fresh install of STM32CubeiDE 1.12.1 RPM.

[Marcelo Jimenez]

Hi @flxzt​ ,

​

While we don't get a proper fix, maybe you can try the script I attached here.

Works like this:

1. Execute STM32CubeIDE and try to create a new workspace, e.g.: ~/STM32CubeIDE/new1
2. Execute "./fix_stm32cubeide.sh ~/STM32CubeIDE/new1"
3. Execute STM32CubeIDE and try to open the ~/STM32CubeIDE/new1 workspace. This time it will crash.
4. Execute STM32CubeIDE again and try to open the ~/STM32CubeIDE/new1 workspace. This time it should not crash.

See if this works for you.

Regards,

Marcelo.

[Semer CHERNI]

Hello @Marcelo Jimenez​ 

I am sorry to inform you that both openSUSE Tumbleweed and Fedora 38 are not fully support at the moment.

This is due to the fact that Linux came in multiple flavors which could not be all covered.

Maybe in the future those Linux version would be added to the list of supported OS which are mentioned in the Release note of the tool.

Kind regards,

Semer.

[PGump.1]

If this issue is the strlen() function, then it has NOTHING to do with the Linux type. It is pure LUCK that it works for some - the strlen() finds a termination sequence before the OS throws a segment or overflow fault!

It's bad code, regardless of the Linux type (or Windows)...

[Marcelo Jimenez]

Hi @Semer CHERNI​ ,

​

Thank you for your answer.​

​

But I must disagree. _I_ am sorry. From my point of view, ST did not even try to address the problem. You see, you have a bug report with logs and backtraces. You have a clear error message with function names (strlen). A simple look at the source code and a programmer could easily fix the problem. You see, you use Java, but ST's answer is that the distribution is not supported. Not only that, you (ST) use _your_ version of Java, not the distribution version. So, if there is someone sorry here, it is me. I am sorry to hear such a bad excuse for not dealing with the problem. And I am sorry to hear that I should not post the problems I find here, because some time ago I happened to choose the wrong Linux distribution to use.

​

I will try to find a workaround and if I find it, I'll post it here.

​

In the meantime, while we hope that at some point in the future, ST will fix the problem, even if by chance.

​

Best regards,

Marcelo.

​

[Pavel A.]

At this point (no support from ST) you can recall that Linux, Java and Eclipse all are free, opensource software. Users are encouraged to help themselves.

From the log above it looks like SIGSEGV exception in strlen, which is called by _dbus_server_get_client_address, which is called by " SWT WebKit", WebKitGDBus.

Either strlen is passed a bad pointer, or a buffer that is not 0 terminated. So you can reach to maintainers of the adoptium distro via https://github.com/adoptium/adoptium-support/issues and ask what to do.

​

​

[Marcelo Jimenez]

Hi @Pavel A.​ ,

Which of couse is something I have done even before starting this thread.

https://github.com/adoptium/adoptium-support/issues/785

Their answer:

"I recommend sending in a bug report to STM32CubeIDE as they first need to investigate that teh are calling the native lib correctly"

And the issue has been closed.

As you said, Linux, Java and Eclipse all are free, opensource software. But STM32CubeIDE is not.

Regards,

Marcelo.

[Pavel A.]

Aha. Then.... three options: give up and use a supported Linux version (maybe even Windows), try the new (buggy) VS Code extension or get the source of suspected component (WebKitGDBus), try to fix it (just sanitize the strlen call) and rebuild. The latter is time consuming, you may want to offer a bounty to Adoptium, or contract somebody else, if motivated enough.

[flxzt]

Thanks! I managed to restore the workspace folder from a previous version, that seems to be workaround as well. But others might find this very useful. Not an excuse to not fix the underlying issue though