-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when trying to go back from "Add Account" or "Delete Account" on Microsoft Store version #3959
Comments
windows again (with its only one process can have a file handle at a time rule)... maybe we can just tell core to schedule it for deletion if it gets this error on windows, or somehow force that it become the sole process opening these files? But now the interesting question would be what files are accessed, I guess blob files, but I'm not sure. |
Any progress on this? |
Not from me. It looks to me like it requires some core knowledge, which I don't have too much of. |
We have We should probably remove this There was also an old issue discussing similar problem: On desktop the error can be ignored, worst case the database remains on disk but it is a small unconfigured database. Core does not garbage-collect accounts folder, maybe we should do it as well to get rid of such databases that we failed to delete. I also opened core issue: deltachat/deltachat-core-rust#5809 |
I made a fix for the core: deltachat/deltachat-core-rust#5814 |
…o `1.142.0` * fix crash on windows #3959
…o `1.42.0` * fix crash on windows #3959
Basically this is how Windows works: Files stored in the Edit: After looking into the log again, I have recognized that the database has been located in the user profile anyway, so mea culpa, and have a nice day! |
…o `1.42.1` - fix crash on windows #3959
Seems to be fixed in current release. Tested on Windows 10. |
1.46.7 ? Nope, still buggy. Are you using the MS Store version? |
Yes. Ok I will uninstall and reinstall to make sure the sandbox paths are used... |
@nicodh Could you please clarify the current state of the issue, if you know off the top of your head? It doesn't affect fresh Microsoft Store installs, but affects all users who at some point had installed the Setup.exe version? Or just the ones who at some point had a pre- 1.46.7 installation? |
I just tried a fresh install in a "fresh" Windows 10 install. The files are in sandbox and a the bug is not reproducable. Can you still reproduce it? Where is your data stored? |
Mine is in |
Ok then we have to investigate further. The path only can't be the problem. I tested Store installs with both paths. |
Here are fresh reproduction steps for 1.46.8:
💥 Delta Chat crashes. Some extra things I did after
💥 Delta Chat still crashes.
💥 Delta Chat still crashes.
💥 Delta Chat still crashes.
💥 Delta Chat still crashes.
It works fine (because it's a Setup.exe version). The only way I managed to NOT reproduce the issue is by installing Delta Chat from Microsoft Store right away, prior to ever installing the Setup.exe version on a particular Windows installation.
✅ Everything works fine! And then if I additionally install the Setup.exe version and launch it, a new directory will be created, In short, I believe that Delta Chat is broken for all Windows users who have had a Setup.exe version prior to |
So I could reproduce this error with the install procedure as described above. The root cause is Since BackendRemote.rpc.removeAccount is called async the app waits quite some time for a response, which comes finally as an error and is catched in OnboardingScreen->onClickBackButton. There we only show an alert dialog if the error is of instance Error which is not the case (??). But there is a error.message, so maybe we should at least show that and redirect to the NoAccountSelected screen by calling window.__changeScreen(Screens.NoAccountSelected) after closing the dialog. That would at least improve the user experience "a bit". Finally it is only possible to solve the root cause in core. We have to find why there is "another process" using the account data. @link2xt By the way - after reloading the website by pressing F5 in dev tools or by clicking the reload button on the crash screen everything works as expected and the temporary account is not visible any more (but the account data still exists on disk) |
electron is likely the other process, like it it still holds a file handle to a file from the accounts blob directory like an image. Also there are tools on windows that you can use to check what programs currently use a file. there is a tool for that in the power toys and you can browse open file handles with process explorer.
|
Some more debugging. I tried to use PowerToys. After clicking the "Delete Account" button, PowerToys shows no processes using the to-be-deleted account's folder. The same goes for the files inside., including After the "Delete Account" is pressed, I can delete the account's directory myself using explorer and it doesn't complain that "it's being used by another process" (which is not the case if I try to delete the folder without pressing "Delete Account"). If I delete the directory manually this way while Delta Chat is hung, it doesn't unhang, but instead, after If I instead delete the contents of the directory while Delta Chat is hung, it doesn't unhang either and, after a minute, the error remains to be the same ( |
This works fine on a manually downloaded 1.46.1, which is also built from 899f196. Note that the manually installed one is 32 bit, and the Mircosoft Store is 64. Idk if this matters.
Here I clicked "Add Account" at 08:43:00, then clicked "back" at 08:44:09, then "back" again at 08:46:00, then "back" again at 08:49:00, then "Let's get started" at 08:49:19, after which the crash occurs:
The manually installed version's log (where everything works fine):
It appears like Core hangs on first "back" click, then on second click it tries to access the file but fails. But it's just my intuition. After the first "back" click it doesn't take much CPU time.
This is not a recent regression. I have been noticing this for a while, at least from 1.44, maybe earlier.
The text was updated successfully, but these errors were encountered: