-
Notifications
You must be signed in to change notification settings - Fork 665
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
[Regression] Client crashes as soon as sync dir becomes unavailable or when sync dir is not available on startup #6049
Comments
@michaelstingl @SamuAlfageme If enough people report this, it might mandate a 2.3.4.. let's see. |
Reproduced & confirmed the regression. (e.g. on OS X):
I think there's some kind of delay on the crash-reporter (last update I see was 18h ago) |
I am seeing similar behaviour on Windows 10 Pro x64 (more similar to #6050 actually). Actually it will crash before generating any logging. Or it will just hang. And then crash silently. Also the crash reporter doesn't work in this case, it will crash as well. So no crash reports Workaround is to run as administrator. Or to assign write permissions to the stack folder. It makes sense the client won't work without write permissions, but it should inform the user about the missing permissions. |
@valentijnscholten This is a little different from my problem. I don't have problem with permissions, but with non existing paths (e.g. external hard drive not mounted) causing the client to crash. |
@progmem64 yes, my issue is more similar to #6050 (folder being readonly), but that is closed and points to this issue for follow up. |
@SamuAlfageme @guruz I can't reproduce on linux. You can't unmount the filesystem with the sync folder while the client is open because it keeps the journal file openend. If I put it on an USB stick and plug it out without unmounting, nothing bad happens. I get |
@ckamm hmmm.. will try to reproduce on leenux (report in #6050 (comment) was over readonly-FS in Fedora and I assumed the same reason was behind it). |
I'm trying the force unmount thing on macOS, and I'm getting #3046, which is not a regression (it not really fixed and still appears in our crash reports). So the regression part could be specific to Windows. |
Just saw that the bug report was created for macOS so this can't really be specific to Windows. I've been trying to reproduce it with current master though, not 2.3.3. |
@jturcotte @ckamm then I was wrong to assume #6050 and this one were the same. 😕 |
It's also possible that one needs a bit of luck in order to reproduce it, on any of the involved OSes. Getting the OS to unmount the disk at the right moment is quite difficult. I tried a few times on macOS and Windows, but could only get it to crash once out of my 10 tries (and it was #3046, so it's either a different issue, or it's not a regression). Having a crash report would help figuring out what is happening. @progmem64 Could take note of the time you submit one or many of the crash reports, so that we can fish them out of the crash reporter? |
On the crash reporter, i see crash because of the
in SqlDatabase::close . Maybe we should remove this ENFORCE and let the code recover. (I thin most of the code should be able to recover) |
@ogoffart Was the stacktrace at all interesting? Yes, it seems this could be an ASSERT instead. It doesn't fix the bug, but there's a reasonable chance of things working anyway. |
https://sentry.io/owncloud/desktop-win-and-mac/issues/370119057/
As I said, i am not sure it is indeed the backtrace relative to this one crash. |
@ogoffart doesn't look so much like it if it's in accountAdded? |
(@guruz: accountAdded is called on startup when the settingsdialog is created) |
It might be that #6129 helps with this problem. @progmem64 would you be up for testing the 2.4 nightly? |
Can confirm it still reproduces on 2.4.1 (build 9367) |
@SamuAlfageme How did you unmount? |
@guruz followed the same procedure as in #6049 (comment) |
I get this on my machine with 2.4 and an idle sync:
This looks to me the same as https://sentry.io/owncloud/desktop-win-and-mac/issues/402884797/ mentioned by @ckamm (Why is it marked as 'resolved' in sentry?) With master branch (newer sqlite3 version) I don't get the crash so easily, I however get it while downloading a file with a different back trace:
BTW
or
With JOURNAL_MODE=delete I manage to get a a crash only in beginning of sync when creating the tables:
Then while the download it doesn't crash, it just errors 👍 :
I'll add a commit that checks for "/Volumes" in sync directory and sets JOURNAL_MODE=delete in code. This should help with most cases.. |
PR for macOS in #6526 Do we need something for Windows? |
Hmm. It's really unfortunate we can make sqlite crash like that. Might a strategically placed |
With WAL mode sqlite seems to occasionally crash when the underlying filesystem goes away.
With WAL mode sqlite seems to occasionally crash when the underlying filesystem goes away.
With WAL mode sqlite seems to occasionally crash when the underlying filesystem goes away. (cherry picked from commit b1224cf)
I've been stressing out the client with forced unmounts both on win and macOS at different points in the sync cycle and I don't seem to be able to make it crash. Closing here as resolved 🎉 |
In context of #6049 a check for the existance of the db file was introduced. That check is performed before every db access... so serveral 100 times per second.
In context of #6049 a check for the existance of the db file was introduced. That check is performed before every db access... so serveral 100 times per second.
In context of #6049 a check for the existance of the db file was introduced. That check is performed before every db access... so several 100 times per second.
In context of #6049 a check for the existance of the db file was introduced. That check is performed before every db access... so several 100 times per second.
In context of #6049 a check for the existance of the db file was introduced. That check is performed before every db access... so several 100 times per second.
Expected behaviour
If storage becomes unavailable, the client should notice and pause sync.
Actual behaviour
The client crashes.
Steps to reproduce
Client configuration
Client version: 2.3.3 (8242)
Operating system: macOS Sierra 10.12.6
OS language: English
Installation path of client: Default
The text was updated successfully, but these errors were encountered: