[Bug]: SIGSEGV crash when maximizing window #41839
Labels
Comments
|
I'm not able to repro this on either Tested on Ubuntu 23.10 w/
No crash @Kilian I am wondering if I'm testing this wrong since your description sounds straightforward. Any idea what I should change from the above so that I can trigger the crash? |
|
quick follow-up to previous comment: @Kilian in the video you made for @VerteDinde, it looks like you are clicking the titlebar instead of pressing f11, so I tried again with that to see if it made any difference. FWIW I still am not seeing a crash |
|
F11 works for me, its the double clicking on the titlebar that causes the crash. So probably WM (I use Mate/Compiz) related. |
|
Tested same setup with ubuntu-mate-desktop 1.291 and compiz 0.9.14.2+22.10.20220822-0ubuntu4, still no crash here. Maybe this depends on hw config? I do not have accelerated graphics configured. |
|
Perhaps a crash dump would be illuminating? const { app, crashReporter } = require('electron')
console.log(app.getPath('crashDumps'))
crashReporter.start({ submitURL: '', uploadToServer: false }) |
|
just checked with 30.0.0, same result. ubuntu-mate-desktop 1.290 (from the ubuntu repo, older than yours) and compiz 0.9.14.2+22.10.20220822-0ubuntu4 (from ubuntu repo too, same as yours) With crashreporter this is the terminal output (dmp file sent to @ckerr) Something that points to it not being WM related is that |
Dump |
3 tasks
|
temporary workaround for anyone experiencing this: (note: requires, obviously, electron29 to be installed) |
|
The issue persists in 30.0.1 as well as 31.0.0-alpha.1 and 31.0.0-alpha.2. |
|
Same issue in our application; we have reverted to version 29 in neanes/neanes#648. |
|
I could not reproduce this only by maximizing/setting Electron to fullscreen. But could reliably produce a crash by creating at least 3 browser windows and then attempting to maximize any of them. Here's a gist: https://gist.github.com/rvcalisto/a8e35699d18189d1d74cada4965ee779 Electron terminated with SIGSEGV on both of my Manjaro and Kubuntu Linux VMs (X11). |
|
same problem. resolve pls |
|
Same problem on Linux Mint. |
|
|
|
I see that no one's attached any logs yet, so I've attached the coredump that shows up in my journalctl when it crashes. Electron version: 30.0.1 Note that the app doesn't need to be fullscreen - simply tiling the app using my WM's keybindings causes it to crash. On the other hand, resizing the window manually seems to be fine. |
|
Threema Desktop is also affected by this when launching under Electron 30.0.1 or 30.0.0-beta.7 (Wayland, Sway WM). There is no fullscreen involved, it immediately segfaults on launch. Launching in floating mode (as opposed to tiled mode) doesn't seem to help either. I can also confirm that 30.0.0-alpha.6 does not segfault, both in tiling and in floating mode, both with and without The stack trace (created using Potentially related to #39449 ? |
|
perhaps related to #41970 |
|
my app has protocol handling, but the issue is also reproducible from the default Fiddle boilerplate, which doesn't. |
|
The changes on the (Crashes happen on Alpha 7, but not on Alpha 6.) I'm fairly sure that from that list only the Chromium bump commit is relevant (from 124.0.6331.0 to 124.0.6355.1). So the change that introduced the crashes in Electron is probably commit b713e34, and possibly a change in Chromium between 124.0.6331.0 and 124.0.6355.1). Additionally, the function that crashes ( |
3 tasks
Some potentially relevant dumps attached in #41879. |
|
Not fixed in 30.0.4 |
|
Unfortunately, #42126 also doesn't fix the issue on my machine in either 30 or 31. |
Same here. Now it crashes faster than in v30.0.0. Attaching the dump file: electron-v30.0.4-linux-x64-symbols-dump-3.txt |
|
@vladimiry "Now it crashes faster than in v30.0.0" - can you say more about this? We're having trouble consistently repro'ing this, so any additional information is appreciated |
Using v30.0.0 I was able to maximize the main window of https://github.com/vladimiry/ElectronMail (the version built from the |
Although I see that |
Just did more testing. Sometimes I'm able to maximize the window without crash with v30.0.4, but it crashes after de-maximizing (still in There are two |
|
I did an ASAN build, and I believe that the |
|
The cast is bad because in the actuality no |
I've just found out that v30.0.4 crashes on Linux on just pure https://github.com/electron/electron-quick-start repo when you just maximize and then de-maximize the window. Make sure it runs v30.0.4 as it doesn't crash on v30.0.0 |
indutny-signal
added a commit
to indutny-signal/electron
that referenced
this issue
May 14, 2024
The frame view of the widget is an `ClientFrameViewLinux` instance only when both `frame` and `client_frame` booleans are set to `true`. Otherwise it is an instance of a different class and thus casting to `ClientFrameViewLinux` is incorrect and leads to crashes. Fix: electron#41839
5 tasks
VerteDinde
pushed a commit
that referenced
this issue
May 14, 2024
Fix cast in ElectronDesktopWindowTreeHostLinux The frame view of the widget is an `ClientFrameViewLinux` instance only when both `frame` and `client_frame` booleans are set to `true`. Otherwise it is an instance of a different class and thus casting to `ClientFrameViewLinux` is incorrect and leads to crashes. Fix: #41839
trop bot
added a commit
that referenced
this issue
May 14, 2024
The frame view of the widget is an `ClientFrameViewLinux` instance only when both `frame` and `client_frame` booleans are set to `true`. Otherwise it is an instance of a different class and thus casting to `ClientFrameViewLinux` is incorrect and leads to crashes. Fix: #41839 Co-authored-by: Fedor Indutny <indutny@signal.org>
trop bot
added a commit
that referenced
this issue
May 14, 2024
The frame view of the widget is an `ClientFrameViewLinux` instance only when both `frame` and `client_frame` booleans are set to `true`. Otherwise it is an instance of a different class and thus casting to `ClientFrameViewLinux` is incorrect and leads to crashes. Fix: #41839 Co-authored-by: Fedor Indutny <indutny@signal.org>
VerteDinde
pushed a commit
that referenced
this issue
May 14, 2024
Fix cast in ElectronDesktopWindowTreeHostLinux The frame view of the widget is an `ClientFrameViewLinux` instance only when both `frame` and `client_frame` booleans are set to `true`. Otherwise it is an instance of a different class and thus casting to `ClientFrameViewLinux` is incorrect and leads to crashes. Fix: #41839 Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com> Co-authored-by: Fedor Indutny <indutny@signal.org>
VerteDinde
pushed a commit
that referenced
this issue
May 15, 2024
Fix cast in ElectronDesktopWindowTreeHostLinux The frame view of the widget is an `ClientFrameViewLinux` instance only when both `frame` and `client_frame` booleans are set to `true`. Otherwise it is an instance of a different class and thus casting to `ClientFrameViewLinux` is incorrect and leads to crashes. Fix: #41839 Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com> Co-authored-by: Fedor Indutny <indutny@signal.org>
|
Can confirm that 30.0.5 runs gracefully. Thanks to everyone involved for a quick fix, especially @indutny-signal. |
nicodh
added a commit
to deltachat/deltachat-desktop
that referenced
this issue
May 15, 2024
Electron < 30.05 crashes on maximize electron/electron#41839
nicodh
added a commit
to deltachat/deltachat-desktop
that referenced
this issue
May 15, 2024
Electron < 30.05 crashes on maximize electron/electron#41839
|
|
Simon-Laux
pushed a commit
to deltachat/deltachat-desktop
that referenced
this issue
May 17, 2024
Electron < 30.05 crashes on maximize electron/electron#41839
Simon-Laux
added a commit
to deltachat/deltachat-desktop
that referenced
this issue
May 17, 2024
…min node to 20 (#3567) * use stdio binary instead of dc node * new local instalation docs * move scripts and module to esm app source will come in next commit * convert app source to esm * complete esm conversion in index.js also reorder import order in some of the files that I touched. * change log message * only use prebuilds and introduce `--allow-unsafe-core-replacement` to lift that restriction for development * fix eslint testing * seems like `--install-links` is not necessary anymore * more info for about screen * remove `--multiple-instances` flag * update import * update min nodejs version from 18 to 20 (because new electron will use that internally) * update electron to 30.0.2 (mainly to allow the new syntax for importing json from esm modules in `@deltachat/stdio-rpc-server`, but also to) don't mind the local paths too much they will be changed before this pr is merge ready * copy stdio transport implementation from core * use npm package * update changelog * Update `@deltachat/stdio-rpc-server` and `deltachat/jsonrpc-client` to `v1.138.0` * pass RUST_LOG to rpc binary * Log signal if stdio process exits with signal * Fix crash of electron Electron < 30.05 crashes on maximize electron/electron#41839 * Update `@deltachat/stdio-rpc-server` and `deltachat/jsonrpc-client` to `v1.138.5` --------- Co-authored-by: Nico de Haen <mail@ndh-websolutions.de> Co-authored-by: link2xt <link2xt@testrun.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Preflight Checklist
Electron Version
30.0.0-alpha7
What operating system are you using?
Ubuntu
Operating System Version
20.04, running on x11
What arch are you using?
x64
Last Known Working Electron version
30.0.0-alpha6
Expected Behavior
Maximizing/fullscreening the app does not sigfault.
Actual Behavior
Maximizing/fullscreening the window crashes the app.
Testcase Gist URL
This is visible in the default Fiddle template that opens with the app
Additional Information
There is no
render-process-goneorchild-process-goneevent called when it crashes.The text was updated successfully, but these errors were encountered: