Rocket.chat.electron: Rocket Chat Desktop segmentation fault on start (Arch Linux)

[xTeixeira]

Hey.
Rocket Chat segfaults on start (doesn't even show the main window) on Arch Linux right now.
Tested with provided binaries (through the rocketchat-client-bin AUR package) and building from source too (through the rocketchat-desktop AUR package).

My Setup

• Operating System: Arch Linux (with GNOME)

• App Version: 2.12.0

• [ x ] I have tested with the latest version

• [ x ] I can simulate the issue easily

[techmunk]

Having the same issue. This seems to be related to glibc update to 2.28. Downgrading to glibc 2.27 and rocketchat works again.

[je-vv]

BTW, building against latest glibc doesn't work either, though it builds just fine. Several things were recompiled on Arch against the new glibc. Rebuilding should be enough, but it happens not to be that way.

[tassoevan]

Since the binaries are built using the Ubuntu Trusty distro, should we consider a upgrade to Ubuntu Xenial (glibc 2.23)?

[xTeixeira]

Well the problem happens even when building on Arch so I'm not sure bumping the Ubuntu version would help with this issue.

Either way since Trusty is really old I think it might be a good idea in general. Maybe even upgrading to 18.04.

[xTeixeira]

Update:
This is probably an issue either with glibc 2.28 or electron (or possibly with the electron and/or glibc packages in the Arch repos), seeing as other electron apps have the same problem after upgrading to glibc 2.28

Sources:
Microsoft/vscode#55934
This reddit thread

[tassoevan]

Apparently lots of software using the prebuilt electron distributions instead of the system electron provided by the Arch Linux official repos, are breaking.

This is bad. I wonder why the Electron from Arch repos is different and if a downgrade can help Arch users.

[tassoevan]

BTW, there is a community-maintained Flatpak for Rocket.Chat that can be a workaround.

[xTeixeira]

@tassoevan A glibc downgrade does work. Although I suppose a flatpack is a much better choice than downgrading such an important package.

Either way, since it _apparently_ only happens on Arch I think it might be a problem with their packages.

Is there a way for me to build Rocket Chat using the electron package in the Arch repos for testing purposes?

[tassoevan]

@xTeixeira Since yarn start is equivalent to run node_modules/.bin/electron ., I'd suggest to try electron . before invoke a build with electron-builder and see what happens.

[xTeixeira]

@tassoevan I tried running electron . (as in using the electron package in arch's repos) and it worked fine even with glibc 2.28. If I do yarn start it works on glibc 2.27 and fails on glibc 2.28. So that's another possible workaround until the issue is resolved.

[taro-yamada]

Hello, I'm interested in this problem.
So I want to build binaries (rocketchat, libnode.so) containing debugging information.
Since I'm not familiar with electron/node.js/yarn/gulp, I searched for a few hours on the net, but I could not find a way to build it.

Is it possible to build binaries that is not stripped?

[tassoevan]

@taro-yamada Yes. The build pipeline of Node.js native addons is orchestrated by node-gyp and, if I remember well, it has a --debug for it. However, Electron build seems more complex in handling binaries and even download some of them (which may be the source of our problems here).

[xTeixeira]

Just to let you guys know, a patch was submitted to Electron, see electron/electron#13988.
Apparently it was an issue with clang.

[engelgabriel]

thanks for the link @xTeixeira

I have done some updates on the https://github.com/RocketChat/Rocket.Chat.Electron/releases/tag/2.13.0-develop but they won't include the FIX as it has not been merged yet.

[eli-schwartz]

Several things were recompiled on Arch against the new glibc.

Nothing was recompiled against the new glibc, that's not even how glibc works. It is backwards-compatible, so older binaries always work with newer versions of glibc.

As mentioned, the prebuilt binaries were built with a faulty toolchain that generated invalid code, which is invalid anywhere -- but older versions of glibc were more forgiving of this particular variety of invalid code.

Any distro with glibc 2.28 (including Fedora rawhide) will see this issue. The electron developers are working on publishing fixed prebuilt binaries.

...

Although it's still a lesson in that programs should use and build against the system electron. :p

[torpesco]

This patchelf hack worked for a colleague and me.

https://github.com/onivim/oni/issues/2497#issuecomment-412030103

Leaves an extra copy of glibc around that will have to be manually cleaned up later.

[xTeixeira]

@torpesco I dont think that's needed. Arch reverted the glibc commit that broke electron to give time for electron upstream to fix it. All you need to do is upgrade glibc to 2.28-4 which is on Arch repos.