4.1b8 sql corruption crash

I'm experiencing an SQLiteException error from a malformed database. The system hibernated last night, and wouldn't "wake up" this morning - so had a clean boot. Loading L4 now crashes fairly quickly.

Right now it only crashes when I try to open my home page, so I can (I think) work without it crashing. I deleted the files under the Home page directory but that availed nothing.

6332.Logos-Log-Files.zip

Find more posts tagged with

Comments

Fred Chapman

Thomas,

I think I remember this crash from a previous Beta as well. I thinking it may have been 4.0c or 4.0d. I tried searching but could not locate the thread. Maybe someone with more time and expertise in searching the forum can find it and it will reveal the fix for this.

TCBlack

https://community.logos.com/discussion/comment/163544#Comment_163544

Well this thread: Crash: Logos 4 Continues to Crash - Logos Bible Software Forums < http://community.logos.com/forums/p/18560/139742.aspx > suggested deletting my library files. I'm not ready to go that far yet. Multiple gig download anyone?

The Wiki states:

http://wiki.logos.com/Logos_4.0b_Crashes">Error ID: 2297 – SQLiteException: The database disk image is malformed

Cause: the index is corrupted
Workaround: Use command “Rebuild Index”

So I guess I'll do a rebuild and see if that cures it. I guess it won't kill me. [:(]

Fred Chapman

https://community.logos.com/discussion/comment/163564#Comment_163564

I'm not ready to go that far yet. Multiple gig download anyone?

Yikes[:O] I hope that's not the problem.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/163564#Comment_163564

The affected component here is not the library index (so rebuilding your index won't help), but the Preferences Manager. This could be bad, because there's no "rebuild preferences" command. You can try deleting the file

C:\Users\tcblack\AppData\Local\Logos4\Documents\cldpfqem.1aj\LocalUserPreferences\PreferencesManager.db

and restarting the app. If that still crashes, also delete

C:\Users\tcblack\AppData\Local\Logos4\Documents\cldpfqem.1aj\UserPreferences\PreferencesManager.db

Unfortunately, this second file contains a lot of your user settings, so you may lose some customisations when it's deleted. (On the other hand, if it's corrupt and unreadable, that's not much good, either.)

TCBlack

https://community.logos.com/discussion/comment/163635#Comment_163635

The affected component here is not the library index (so rebuilding your index won't help), but the Preferences Manager. This could be bad, because there's no "rebuild preferences" command.

Oh. Well. At least my index is new and shiny.

Deleting the first file did the trick! So it must have been in the middle of a write or something along that line when the hibernation began?

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/163650#Comment_163650

Deleting the first file did the trick! So it must have been in the middle of a write or something along that line when the hibernation began?

The SQLite database is supposed to recover gracefully from power interruptions, hibernation, crashes, etc. (which is one of the reasons we chose it; see http://www.sqlite.org/atomiccommit.html for all the gory details). However, we are seeing a small (but worrying) number of reports of "malformed database" errors; I don't yet know if that's caused by a Windows-specific bug in SQLite, an error in the way we're using SQLite, faulty underlying hardware, or some other cause.

TCBlack

https://community.logos.com/discussion/comment/163910#Comment_163910

OK, I'm sick. I enjoyed reading most of the article. :-)

Is there something I should do to try to replicate this with better logging?

Dave Hooton

https://community.logos.com/discussion/comment/164049#Comment_164049

OK, I'm sick. I enjoyed reading most of the article. :-)

Is there something I should do to try to replicate this with better logging?

Perhaps you should consider disallowing hibernation which is what I do on the laptop. I frequently put it to sleep whilst L4 is still running and have no issues.

Doug

https://community.logos.com/discussion/comment/163910#Comment_163910

The SQLite database is supposed to recover gracefully from power interruptions, hibernation, crashes, etc. (which is one of the reasons we chose it; see http://www.sqlite.org/atomiccommit.html for all the gory details). However, we are seeing a small (but worrying) number of reports of "malformed database" errors; I don't yet know if that's caused by a Windows-specific bug in SQLite, an error in the way we're using SQLite, faulty underlying hardware, or some other cause.

Maybe you guys should consider including a command that would delete this file and rebuild the database. If this "worrying" number of reports is of concern, then maybe the problem is widespread enough that there should be a way to address it without users having to go into their files. Some users may not be computer savy enough to comfortably perform the file detetions.

TCBlack

https://community.logos.com/discussion/comment/164127#Comment_164127

@Dave,

I thought about it. But IMHO it's Logos that needs to modify the way they handle this. The Hibernate feature/function is fairly robust in Win7 - and no other programs suffer along with it. But I'm willing to court disaster by crashing Logos if it helps them to track down what's going on, and issue a "stop hibernate till I'm done writing" if necessary. (I"m sure that command exists somewhere. [:p])

Maybe you guys should consider including a command that would delete this file and rebuild the database. If this "worrying" number of reports is of concern, then maybe the problem is widespread enough that there should be a way to address it without users having to go into their files. Some users may not be computer savy enough to comfortably perform the file detetions.

Rather than a command, it should be done behind the scenes. When the error occurs the file should be automatically repaired or deleted, with a message given to the user, "Logos has detected corruption in your personalized settings database. We have attempted to rebuild the index, please check your settings. The program will now restart."

Dave Hooton

https://community.logos.com/discussion/comment/164134#Comment_164134

I thought about it. But IMHO it's Logos that needs to modify the way they handle this.

Yes - the suggestion was a defensive one, aimed at minimising occurrences on your machine because Logos have been on the back foot trying to isolate this issue. The SQLite article was very sobering with regard to operating system fallibilities.

Dave Hooton

https://community.logos.com/discussion/comment/164134#Comment_164134

Maybe you guys should consider including a command that would delete this file and rebuild the database. If this "worrying" number of reports is of concern, then maybe the problem is widespread enough that there should be a way to address it without users having to go into their files. Some users may not be computer savy enough to comfortably perform the file detetions.

Rather than a command, it should be done behind the scenes. When the error occurs the file should be automatically repaired or deleted, with a message given to the user, "Logos has detected corruption in your personalized settings database. We have attempted to rebuild the index, please check your settings. The program will now restart."

Currently there are few, if any, situations from which Logos choose to recover gracefully. So we have a corrupt Biblical People/Places record and L4 crashes leaving the user to figure things out after repeated crashes!

To prove the point I just got a crash after accessing Biblical People -> the SyncManager "cannot access this object because a different thread owns it.". And another crash directly from Biblical People -> "Value cannot be null.". If you know how avoid accessing "Holy Spirit", "Yahweh" ....