Arch Linux User Repository

No segfault here on 4.34.120 as pulled today with --ozone-platform=wayland on kwin on electron 25.

sha256sum fe2c78539f31cf8e58ae2250af428d00637f0d59af987113f31d7f0f8db48d72

exec electron25 --ozone-platform=wayland /usr/lib/slack/app.asar "$@"

Did some more debugging, here's what I get from gdb for the segfault (4.34.120 + wayland):

$ gdb --args /usr/lib/electron25/electron \
  --ozone-platform=wayland \
  /usr/lib/slack/app.asar
(gdb) run
...
(gdb) bt
#0  0x000055555af83cdb in GURL::GURL(GURL const&) ()
#1  0x000055555af83d7d in GURL::GURL(GURL const&) ()
#2  0x0000555559ff52ca in content::SiteInfo::SiteInfo(content::SiteInfo const&) ()
#3  0x0000555559d98640 in content::ProcessLock::ProcessLock(content::ProcessLock const&) ()
#4  0x0000555559a5033d in content::ChildProcessSecurityPolicyImpl::GetProcessLock(int) ()
#5  0x0000555559dbe5f2 in content::CodeCacheHostImpl::GetCodeCache(blink::mojom::CodeCacheType) ()
#6  0x0000555559dbf1b2 in content::CodeCacheHostImpl::FetchCachedCode(blink::mojom::CodeCacheType, GURL const&, base::OnceCallback<void (base::Time, mojo_base::BigBuffer)>) ()
#7  0x000055555871b201 in blink::mojom::CodeCacheHostStubDispatch::AcceptWithResponder(blink::mojom::CodeCacheHost*, mojo::Message*, std::unique_ptr<mojo::MessageReceiverWithStatus, std::default_delete<mojo::MessageReceiverWithStatus> >) ()
#8  0x0000555559dbff97 in blink::mojom::CodeCacheHostStub<mojo::UniquePtrImplRefTraits<blink::mojom::CodeCacheHost, std::default_delete<blink::mojom::CodeCacheHost> > >::AcceptWithResponder(mojo::Message*, std::unique_ptr<mojo::MessageReceiverWithStatus, std::default_delete<mojo::MessageReceiverWithStatus> >) ()
#9  0x000055555ac596cc in mojo::InterfaceEndpointClient::HandleValidatedMessage(mojo::Message*) ()
#10 0x000055555ac5f9a2 in mojo::MessageDispatcher::Accept(mojo::Message*) ()
#11 0x000055555ac5ae51 in mojo::InterfaceEndpointClient::HandleIncomingMessage(mojo::Message*) ()
#12 0x000055555ac62d1a in mojo::internal::MultiplexRouter::ProcessIncomingMessage(mojo::internal::MultiplexRouter::MessageWrapper*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) ()
#13 0x000055555ac62592 in mojo::internal::MultiplexRouter::Accept(mojo::Message*) ()
#14 0x000055555ac5f9df in mojo::MessageDispatcher::Accept(mojo::Message*) ()
#15 0x000055555ac5745e in mojo::Connector::DispatchMessage(mojo::ScopedHandleBase<mojo::MessageHandle>) ()
#16 0x000055555ac57db3 in mojo::Connector::ReadAllAvailableMessages() ()
#17 0x00005555575a698b in base::RepeatingCallback<void (int, int, int, int)>::Run(int, int, int, int) const & ()
#18 0x000055555ac75232 in mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) ()
#19 0x000055555aa96edc in base::TaskAnnotator::RunTaskImpl(base::PendingTask&) ()
#20 0x000055555aabc8f8 in base::internal::TaskTracker::RunTaskImpl(base::internal::Task&, base::TaskTraits const&, base::internal::TaskSource*, base::SequenceToken const&) ()
#21 0x000055555aabcee2 in base::internal::TaskTracker::RunSkipOnShutdown(base::internal::Task&, base::TaskTraits const&, base::internal::TaskSource*, base::SequenceToken const&) ()
#22 0x000055555aabc685 in base::internal::TaskTracker::RunTask(base::internal::Task, base::internal::TaskSource*, base::TaskTraits const&) ()
#23 0x000055555aabc2b5 in base::internal::TaskTracker::RunAndPopNextTask(base::internal::RegisteredTaskSource) ()
#24 0x000055555aac4231 in base::internal::WorkerThread::RunWorker() ()
#25 0x000055555aac3f9a in base::internal::WorkerThread::RunSharedWorker() ()
#26 0x000055555aac3df2 in base::internal::WorkerThread::ThreadMain() ()
#27 0x000055555aadcc1a in base::(anonymous namespace)::ThreadFunc(void*) ()
#28 0x00007ffff3a8c9eb in start_thread (arg=<optimized out>) at pthread_create.c:444
#29 0x00007ffff3b10dfc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

This doesn't say much to me, but maybe to someone else.

Perhaps 4.34.120 is better on wayland than 4.34.115?

The latest version, 4.34.115, crashes on launch for me on Wayland, both with Electron 24 and 25.

Holding the package at 4.33.90 until I have time to investigate. Feel free to build and test the latest version yourselves, help is very much appreciated.

@amezin Regarding the Electron version, with v25 + Wayland Slack segfaults on launch for me, hence the dependency to v24.

Regarding login issues: when run under system electron (the version doesn't matter) - slack doesn't create ~/.config/Slack/Singleton{Cookie,Lock,Socket}. And then doesn't detect that another instance is already running.

The code that should create them is from Chromium/electron - nothing specific to Slack: https://www.electronjs.org/docs/latest/api/app#apprequestsingleinstancelockadditionaldata - the only question is why Slack isn't calling it. Looking at the code extracted from app.asar, it at least depends on app.isPackaged: https://www.electronjs.org/docs/latest/api/app#appispackaged-readonly

In current electron-desktop:

$ cat /lib/slack/version
25.2.0

Shouldn't this package depend on (and run) electron25?

No you are not. Install slack-desktop, login with that one, than get back to slack-electron and you will be logged in. At least this works for me sometimes.

Am I the only one suffering from the issue of logging in to a workspace open a new Slack instance?

Sorry I wasn't clear enough, with slack-desktop I could always login without problem. With electron version, I could not. So I would login with the desktop version, save the ~.config/Slack dir, then install electron version and I would be logged in already. This stopped working yesterday, but this morning it works again. So really hard to debug what's going on I guess.