Random SIGTRAPs in DecommitSystemPages on some platforms (e.g. Arch Linux) #691
Comments
|
I updated my element and (in case it matters) nodejs-electron packages on opensuse tumbleweed to
Since then, element will crash on startup. I've tried removing my electron and element config, and the problem still occurs, a split second after the window is first shown and the contents load. The terminal output is similar to above, but slightly different, and in my case element always crashes on startup so I'm not sure whether this warrants a new issue ticket or not. The apparent "dlopen" error doesn't sound so good... Output: |
|
Updating electron to 16.0.8-1.1 seems to have fixed it for me. |
|
I celebrated too early, it crashes again. I don't know why it worked for a bit... might be config/state dependent like in OP's case. |
|
Like I noted, it appears to just be completely random for me. If I could figure out where the core dump is, I could rebuild the latest stable and debug it, because I strongly suspect this is a bug in the underlying native code, not element itself. I can't imagine how element could cause a crash like this. |
Where the coredump ends up depends on how your See https://man7.org/linux/man-pages/man5/core.5.html for the documentation of the placeholders. For some reason the build-ids for the debug symbols in my distro don't match the actually installed library, so I can't resolve the addresses in my coredumps. Maybe it'll work for you? |
|
It appears that I'm using systemd-coredump(8) for core dumps. I don't think I can dump all the cores (it says "More than one entry matches, ignoring rest") but I've attached the dump it did create. The output from |
|
I'm hoping that that doesn't contain anything sensitive. If it does I'll have to rotate all the keys my element install uses. Oops? |
|
Now I'm wishing GitHub had the "mark issue/comment as confidential" like GitLab does. |
coredumps contain the memory of the process, so theoretically it might contain sensitive information, yes. I guess I should've warned about that 😬 Imo these privacy concerns should be advertised more here (and in issue trackers in general). More on topic, it looks like you're also missing debug symbols (or at least whatever generated the stacktrace couldn't find them). If your core_pattern is set to pipe coredumps to systemd, you can always just change it to a regular file path and it should bypass systemd. Not sure you'll get more out of it though if you're missing debug symbols. |
|
Damn. Guess I'll have to figure out how to rotate the keys Element uses. And I can't seem to build element, unfortunately, so I can't get debug symbols. :sad: |
|
Could this be an instance of element-hq/element-web#20813 (comment) |
Hm, never say never but that issue seems to exhibit a white screen and no (hard) crash, while my element crashes at startup, the process exiting. For a split-second it loads some GUI elements, and then it crashes hard. |
|
This is happening to me too, also on Arch Linux. Only seems to happen when signing in a new device. I once arbitrarily managed to get past the sign-in without a crash and then afterwards it worked fine. Tried downgrading the |
|
I have experienced this as well. My investigations prove that it happens way more often in Wayland than in Xorg, but doesn't mean Xorg is immune. Today I got it in my desktop (which has X) and during weekend was having it regularly (I think I reached 11 core dumps throughout the day) in the laptop running wayland. Same distro Arch Linux. I tried compiling the |
This is expected as we strip debug symbols on Arch by default. We are currently in the process of rolling out split debug packages (distro-wide), and @inglor is currently rebuilding electron15 for this. Once available, it should be possible to get debug symbols from future dumps. Also, your own issue is likely different, because all the reports so far (here and oob) are from Arch. And finally, I must say I don’t have any crash at all on my side… |
|
Managed to get it core dump while using debug electron15: gdb backtrace here: |
|
This is also happening to me, after freshly installing Element on a new PopOS instance, using flatpak. Edit: I've been able to fix this by restarting my PC, i think some pending GPU/system changes were making element unstable |
|
Element Desktop ( |
|
For anyone looking to get a backtrace and is on Arch Linux you can install the unstripped package of Then once you can reproduce it with after install all you need to do to get a backtrace is After you get the |
|
Here's the stack trace The trap seems to happen due to an invalid instruction being executed: |
|
Most of the crashes in this issue are about getting a SIGTRAP on Arch in DecommitSystemPages, so making this issue about that. |
novocaine
changed the title
@barathrm I believe this is a different issue to other people's - the others in here are all on Arch, but you are on SUSE and received this specifically whereas the others aren't This looks like a packaging issue with keytar. But after upgrading, it sounds like maybe you're now receiving a crash at a different time, not at startup? Can you post new logs from your current crashes if you're still getting them? |
|
tensor5/arch-atom#34 looks similar. There is some discussion there of In that issue, I think there was an incompatibility between glibc and the kernel version. I believe the cause is the same here; i.e this is a packaging issue with Arch and needs to be reported upstream against https://archlinux.org/packages/community/x86_64/element-desktop/ |
|
I think my crash logs in element-hq/element-web#20467 (comment) are probably related to this. |
@inglor This trace was extremely helpful - I don't suppose you have notes on creating a debug build, as others have struggled with this. |
|
Re. debug builds, see #728 |
|
@novocaine the debug build of electron15 specifically for Arch Linux is pretty simple: Greater values of |
This comment was marked as abuse.
This comment was marked as abuse.
|
The odd thing is that this only occurs on Arch. It doesn't occur on any other Distro I've used. Not Ubuntu, not Debian, not Fedora, not NixOS... Just Arch. So, other than the version (since Fedora and NixOS have the latest version of Element/Electron), what makes Arch unique? Clearly, Arch is doing something different. Somehow, I doubt it's the "system-wide Electron" thing they've got going, either. |
I'm pretty sure I've experienced this on Debian Bookworm, see element-hq/element-web#24853. |
I've personally experienced this on Fedora Workstation 37, in the past. |
|
I've experienced it on my Fedora 37 - on two systems (on bare-hardware laptop and in the VM). |
|
This does happens in a fresh install of Fedora 37. @andrew-demb How do you disable search in Element ? |
"Message search" in the Element Security & Privacy settings. |
It seems to have fixed the issue for now. Thanks. |
weeman1337
added
O-Occasional
|
The crash (SIGTRAP in chromium's It appears to crash in about 30-50% of attempts when doing for example Looking at strace, there are |
I can confirm a relation with the search, because I can trigger the SIGTRAP with building the search index (all settings->security & privacy->Message Search->Manage). element disappears immediately. Any news about this bug? Disabling the search is no option for me... |
|
Any News? |
1 similar comment
|
Any News? |
|
I no longer run into this issue on Arch. Have you tried the client again recently? |
Sadly still a show-stopper for me. [Ubuntu 22.04, FWIW] |
|
Same. Still broke on my PopOS install :( |
|
oh, and apparently @MatMaul did some groundwork here too |
and others
Steps to reproduce
I'm not really sure what causes this, but the element desktop client isn't very stable. Sometimes, when switching between rooms via alt+up/alt+down, it crashes without any warning or anything; other times, like just now, it crashed, again, even though I wasn't doing anything other than chatting, and when I tried reopening it in the console after it crashed several times in sequence it said "Trace/breakpoint trap (core dumped)". I can't seem to find said core dump, nor can I seem to find the cause. I wish I could provide more info (maybe there's a way to do it and I just don't know).
Outcome
What did you expect?
I expected Element to start correctly.
What happened instead?
Element crashed several times, and tends to crash at random.
The output in the console before it crashed follows:
Operating system
Arch Linux
Application version
Element version: 1.10.1, Olm version: 3.2.8
How did you install the app?
I installed the app from the Arch Linux repositories via pacman.
Homeserver
I'm using synapse 1.51
Will you send logs?
No
The text was updated successfully, but these errors were encountered: