Tutanota: Tutanota-Desktop-bin has been crashing here continuously since today.

[HeinzDo58]

Tutanota-Desktop-bin has been crashing here continuously since today.
https://pastebin.com/57CmGKWi
I use arch linux.

[charlag]

Hi
It's not clear what's going on there to be honest. Is there anything special, location, read-only, possible missing deps?
You can try installing libsecret even though it should not be necessary

[ganthern]

Did this problem persist with the package version 3.67.3-4 from the AUR? They seem to have made some changes in the past few hours. I'm also on Arch Linux, but have the client installed manually. No crashes here.

We would also need a little more information about your environment since Arch Linux ist pretty close to a DIY-Distro with respect to the possible setups. At least your DE and installed extensions with versions and a better description of the process from arch boot to tutanota crash.
This is also the reason we have a template for reporting bugs.

Thanks for the report!

[HeinzDo58]

Yes, the problem unfortunately still exists.
It keeps crashing and then restarting. And in an endless loop.
I use arch linux with KDE Plasma 5.18.
I have this problem since 2 days.

[HeinzDo58]

I Maybe this helps here?
These are the messages when the desktop client starts.

tutanota-desktop
[2020-02-13T10:27:33.887Z] the monkey has been patched
libsecret-Message: 11:27:33.908: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files
[2020-02-13T10:27:33.912Z] _connectedSseInfo undefined
[2020-02-13T10:27:33.913Z] scheduling to reconnect sse in 1 seconds
[2020-02-13T10:27:33.913Z] argv: [ '/opt/tutanota-desktop/tutanota-desktop' ]
[2020-02-13T10:27:33.914Z] version: 3.67.3
[2020-02-13T10:27:33.929Z] alarm storage failed to initialize: [Error: The name org.freedesktop.secrets was not provided by any .service files]
[2020-02-13T10:27:33.933Z] startFile: file:///opt/tutanota-desktop/resources/app.asar/desktop.html
[2020-02-13T10:27:33.984Z] default mailto handler: false
[2020-02-13T10:27:34.581Z] Webapp ready
[2020-02-13T10:27:34.582Z] checking for /home/heinz/.local/share/applications/tutanota-desktop.desktop ...
[2020-02-13T10:27:34.582Z] desktop file exists, checking version...
[2020-02-13T10:27:34.914Z] scheduling to reconnect sse in 10 seconds
[2020-02-13T10:27:34.914Z] sse info not available, skip reconnect
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0230
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0230../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall

[2020-02-13T10:27:38.524Z] browserWindow crashed, trying to reopen at /login
[2020-02-13T10:27:38.528Z] startFile: file:///opt/tutanota-desktop/resources/app.asar/desktop.html
[2020-02-13T10:27:39.853Z] saving bounds: {
fullscreen: false,
rect: { x: 560, y: 251, width: 800, height: 607 },
scale: 1
}
[2020-02-13T10:27:44.917Z] scheduling to reconnect sse in 10 seconds
[2020-02-13T10:27:44.917Z] sse info not available, skip reconnect

[sofiageo]

Did this problem persist with the package version 3.67.3-4 from the AUR? They seem to have made some changes in the past few hours. I'm also on Arch Linux, but have the client installed manually. No crashes here.

I was having the same issue after updating my Arch installation. I'm using the Tutanota appImage(3.67.3) so It's not just an issue of the AUR package. I'm on Gnome by the way. The issue kept happening when using the Desktop entry. When I tried to run the client from the appImage file in my terminal so I can see what's wrong, it stopped crashing. So I guess it's something wrong with the Desktop integration, which has now fixed itself.

Edit: after about 15 minutes, it started crashing again in a loop.

Log:

../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 02300230

[2020-02-13T12:45:52.048Z] browserWindow crashed, trying to reopen at /mail/LjcNwR8--V-1/M-yCFZP----2
[2020-02-13T12:45:52.052Z] startFile:  file:///tmp/.mount_tutanobRhqp9/resources/app.asar/desktop.html
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0230

[sofiageo]

Googling a bit reveals it might be an issue with glibc and Chromium. So I post my verisons here as well:

glibc: 2.31-1 (build date: 02 Feb 2020)
Chromium: 80.0.3987.100-1 (build 11 Feb 2020).

So it looks like a regression on Chromium ?

[sofiageo]

I'm not really sure how Tutanota electron client is working but I noticed that electron 8 has been packaged today. I just installed it and waiting for another crash at the moment. Will report if that was the issue.

[sofiageo]

This issue is definitely fixed, the problem was electron 7 package which was using an old version of chromium

The fix landed in chromium 80.0.3983.2 as you can see here: https://bugs.chromium.org/p/chromium/issues/detail?id=1025739

Electron 8 fixes it which is now available in Arch Linux.

[HeinzDo58]

Then this fix only has to land in Tutanota.
So far, the desktop client has been crashing every second.

[charlag]

We will depend on Electron 8 with the next version so should be fixed soon.

[sofiageo]

Then this fix only has to land in Tutanota.
So far, the desktop client has been crashing every second.

Yeap, took about 22 minutes this time but it crashed again even with electron 8 in Arch. I'm not sure why it takes so long to crash on my PC :)

[sofiageo]

I confirm that after about 3 hours with 3.67.4 no crashes have occurred. Thanks.

[ganthern]

I'll close this then.

FTR, it did crash for me after all, but not frequently and it restored the window when it did, so I did not notice.