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

[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.

[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.

[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 · Accepted solution]

Hi @flxzt​ ,

A better hack has been found.

Just do:

$ mkdir /tmp/SWT-GDBusServer

And then start the IDE.

https://github.com/adoptium/adoptium-support/issues/785#issuecomment-1585893229

Regards,

Marcelo.

[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