-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Fresh install gives error on every launch #22
Comments
Correction: DB is created, and entries are written to it normally, and show up rhe next launch. But UI popup "An error occurred" and log message appear on each launch. |
Actually, there's both variants. Sometimes, an error popup "The Database could not be loaded" appears. After this, no new entries are saved. As long as this does not appear, entries get saved and restored normally. |
Thanks for reporting, that is a nasty bug! I just fixed a bug that I encountered when creating a new database. However, I can't reproduce your exact problems. I'll create a new release later, and maybe the issues you encountered will be fixed by that already. Otherwise I'll have to investigate further. |
I have applied b77c363.diff locally but the issue remains the same AFAICS. |
Some more sleuthing (and this is without b77c363), on a Gemini PDA running 4.6.0.13. (The original error appears on a XPeria10III running 4.4.0.72). Removed Launching manually:
Prettified stack trace:
After this, dconf key is:
If I now reset the dconf key It seems some part of the migration fails, but dconf records it as successful. Or something like this. |
Aha! trying the same thing on the Gemini with b77c363 applied shows no errors! Summarizing the differences: GeminiPDA, SFOS 4.6, b77c363 seems to fix things.
Xperia 10 III, SFOS 4.4, always shows the originally reported error, both with and without b77c363.
(The pyotherside difference is just packaging, no functional changes.) |
Hm. Going back to That is called from It appears initialization of those components triggers a call to the function at a point in time when At least adding some prints seems to indicate this:
gives the "expected":
AFAIK initialization order of components in QML is more or less undefined, which would explain the "raciness" of the error. |
Some other changes to
reveals that it is indeed called with empty strings sometimes. The |
Thank you for the analysis! I adapted the code from your last comment and I think that should properly fix it. My theory is this: when the app is started without a lock code and the database creation is slow, then normalizeText() is called from the tags model on the attached write page before the backend is ready. In that case it's ok to fail gracefully, as no data should be entered at this point. |
On a new/fresh install I get the error in the logs:
The app gives a popup about an error and to check the logs.
I guess the database is never created, or at least can not be accessed properly.
Entries can be created, but are not saved and lost on next app launch.
The text was updated successfully, but these errors were encountered: