Crash on exit #19842
Comments
|
Thank you for taking the time to report this issue and helping to make Electron better. Would it be possible for you to fork electron-quick-start for a small app that reproduces the issue by itself? Standalone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unneccessary variables from the equation, and it can also provide the basis for automated regression tests. I'm adding the Thanks in advance! Your help is appreciated. |
ckerr
added
blocked/need-info ❌
|
@ckerr I've tried to repro this on a vanilla electron app, however without any luck. I think it would be less effort by far if the crash log attached could be symbolicated, then we would see where it goes off the rails |
|
OK I ran symbolication myself, turned out the crash happens in notification handling code. I'll try reproducing it in the From what I can tell the following line causes crash: See the crash.txt file attached to the issue. |
|
The same crash on 4.2.9 So far I was not able to repro this in the |
|
@ckerr I've updated the issue with the branch that you can use you to reproduce the crash. |
|
@ckerr did you have a chance to have a look at my findings? I've updated to the latest macOS and the crash happens even more often... 😢 |
sofianguy
added
5-0-x
6-0-x
and removed
blocked/need-info ❌
|
Hi. The same issue also occurs on Electron 8.0.0. I'm running macOS 10.13.6. The application crashes about 1 in 10 times when i press the "QUIT" button. |
|
At Tutanota it happens very often to us and our users and stacktrace also indicates that this is notification problem (we are on 4.2.6 currently) Crash report |
|
I think I have a good idea of what's going on. Stacktraces all lead here: (uses NotificationDelegateImpl in the same file)
and here (uses itself as a delegate) In the first case there are no other references to the delegate and it seems to be on heap so, well, it shouldn't disappear if I understand anything. In the second case but when it is destroyed it tries to set delegate to electron/shell/browser/api/atom_api_notification.cc Lines 77 to 80 in 0fe6767 I thought I was lost at this point but! There's a condition in this code. "can this reference change?" yes, it can change! It is reset here: electron/shell/browser/api/atom_api_notification.cc Lines 205 to 210 in 0fe6767 so when you close the api notification, it forgets about the platform notification and then when it is destroyed it will not call this That's just a theory but if anyone has build setup set already (or if anyone from the Electron team reads this) it would be nice if you could try adding |
5 tasks
|
Looks like this crash reproduced in 9.0.0. |
|
Electron version: 12.1.1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Preflight Checklist
Issue Details
Hi,
I intercept the app shutdown using
before-quitevent handler and callpreventDefaultwhen I receive the event in the very first time. Then I do some clean up and callapp.quit()once again to make sure that the normal termination happens.The app terminates and a crash report dialog appears (excerpt below)
Symbolicated crash report:
crash.txt
Based on the crash report, the
Notificationdestructor triggers the crash. So I've poked around creating Notifications in JS and somehow I've managed to crash the app when creating notifications from thebefore-quithandler.I can't really explain why creating notifications from the
before-quitdoes crash the app, because in the case of my own app, it does crash regardless that, i.e I can just create one notification at the start and the app will crash on exit anyway.It's possible that the amount of allocated memory plays its role. Perhaps some of notifications are being evicted from memory sooner when more JS objects are being allocated. It's possible that it's a double-release issue.
Also, I think the fact that I retain the notifications in array affects the garbage collection somehow.
The crash itself is not 100% reproducible but it happens often enough. So if you run my branch a few times in a row, you should see the crash dialog.
You can observe the
ReportCrashprocess in activity monitor (see the screenshot I've attached to the issue). If you see theReportCrashspike in CPU usage, wait a little before it pops the crash report dialog. It takes some time to symbolicate the crash log if you have DSYMs installed.I've also tried to
destroy()notifications manually which caused the following output in console:and such output too:
So I suppose something is over-releasing the memory...
Expected Behavior
No crash
Actual Behavior
Crash
To Reproduce
Press "quit" button in the application window
See the crash report dialog appear (with a certain success rate)
Screenshots
Additional Information
The text was updated successfully, but these errors were encountered: