Switched from one layout, which had loaded fine and was working without a hitch, to another layout. After populating the chosen layout, Logos quit unexpectedly. Logs attached: 6507.Logging.zip
Mark...
I am no expert on logs but from your Logos Error record...
Program Version: 5.0 SR-4 (5.0.0.1835)
Time: 2012-11-20 18:29:04 +01:00 (2012-11-20T17:29:04Z)
Error retrieving groups for resource LLS:1.0.710, 2012-11-01T16:52:55Z.
I would guess the first thing to do is update to version 5a?
Hey Mike, thanks for looking into that. Odd that the logs report 5.0, because I've already been updated to 5.0a for a few days now. I verified the version under "about Logos" and even ran "Update Now" before replying to you here, which resulted in "No updates available"
No you are running 5.0a
Program Version: 5.0a (5.0.1.0220)Mac OS Version: 10.8.2Architecture: x86_64Model: MacBookPro9,2
The crash was due to the SQLite database (which is embedded DB on OS X) being unable to open one of the Logos databases. Logos uses various databases for recording data.
I am beginning to suspect that there is some code/database physical file issue with the Mac version of Logos 5. I am getting a significant number of crashes on my installation that I did not use to get on Logos 4. I have now turned on logging on my system and am going to be looking at this.
For your case see if you can start Logos 5 again.
ONE QUESTION: when you got the crash did you see the OS X dialog box which says that program X crashed do you want to report this to Apple?
Patrick, thank you for verifying. To answer your questions, after collecting and posting the logs I tried and was able to boot L5 no problem. And yes, the OSX crash dialog appeared afterwards.
OK. See how you go, keep logging enabled. When (IF we hope not) you get a crash again take note of whether you see the OS X dialog box advising of application crash and mention it in your forum posting. For the first time using Logos I am getting crashes where it just drops out instantly with no OS X dialog. This is really (really) not nice because the crash is not even noticed by the operating system.
What I saw in my crash log was error too many files open, I am reading — apart from the common situation where someone's installation tries to open a corrupt resource — two types of crash cases in the forum: SQLite database (corrupt, can't find) and 'too many files open'.
No you are running 5.0a Program Version: 5.0a (5.0.1.0220)Mac OS Version: 10.8.2Architecture: x86_64Model: MacBookPro9,2
Thanks Patrick - the logs really ought to be locked to keep fools out [:(]
Thanks Patrick - the logs really ought to be locked to keep fools out
C'mon [:)] don't be hard on yourself, you may have been looking at beginning of general log. I went straight to the crash log.
Technical stuff is my interest and job so it's (relatively) easy.
I don't know if Logos or anyone in the user community has made a database checker for the Logos database files, I am looking at it out of interest. Command line checking is easy... this below checks a copy of one of the Logos SQLite databases
=====================
Patricks-iMac:SQLite patrick$ sqlite3 /LogosTest/UserPreferences/PreferencesManager.dbSQLite version 3.7.12 2012-04-03 19:43:07Enter ".help" for instructionsEnter SQL statements terminated with a ";"sqlite> PRAGMA integrity_check;oksqlite>
to get a general use tool with a simple user interface will be more difficult obviously.
whether you see the OS X dialog box advising of application crash and mention it in your forum posting.
When I get those, I usually copy it into a TextEdit file and attach that to the forum post. Do you think this will provide useful information to the Logos development folks?
whether you see the OS X dialog box advising of application crash and mention it in your forum posting. When I get those, I usually copy it into a TextEdit file and attach that to the forum post. Do you think this will provide useful information to the Logos development folks?
I would believe the more information the development guys have regarding a crash the better — working on the assumption that one can never have too much information.
The main reason I mentioned about noting if the OS X crash report dialog comes up is because I have started getting crashes where Logos just immediately terminates and it is not picked up by OS X operating system. This is, to me, a bit more serious and it would be good to see if there was any consistent problem related to it — for example if it occurs only when Logos reports too many open resources, or when an SQLite DB is the issue, or a missing/corrupt resource.
whether you see the OS X dialog box advising of application crash and mention it in your forum posting. When I get those, I usually copy it into a TextEdit file and attach that to the forum post. Do you think this will provide useful information to the Logos development folks? I would believe the more information the development guys have regarding a crash the better — working on the assumption that one can never have too much information. The main reason I mentioned about noting if the OS X crash report dialog comes up is because I have started getting crashes where Logos just immediately terminates and it is not picked up by OS X operating system. This is, to me, a bit more serious and it would be good to see if there was any consistent problem related to it — for example if it occurs only when Logos reports too many open resources, or when an SQLite DB is the issue, or a missing/corrupt resource.
Apple Diagnostic Crash Report with corresponding Logos diagnostic log files is helpful. The Apple crash reports are in ~/Library/Logs/DiagnosticReports and begin with Logos along with including date and time of crash in file name.
Keep Smiling [:)]
I don't know if Logos or anyone in the user community has made a database checker for the Logos database files, I am looking at it out of interest. ... to get a general use tool with a simple user interface will be more difficult obviously.
SQLite Manager extension is available for Firefox, which can open many Logos database files on OS X and Windows. The default option for database file extension is sqlite; changing to db is a bit quicker to use with Logos.
I am beginning to suspect that there is some code/database physical file issue with the Mac version of Logos 5.
Quite a number of different resources could not be FOUND at /Users/marknigro/Library/Application Support/Logos4/Data/cgrjrfqr.6v7/ResourceManager/Resources. But prior to that the "Too many open files" message was issued by Mono (I would say .NET in Windows).
The final error is likely the ResourceManager database that can't be opened** but there is no indication it is corrupt.
Mark try to limit collections with a large number of resources ticked for Parallel Resources i.e. remove the tick, not the collection.
I think there is a systemic error that Logos need to look at.
** I hesitate to recommend deleting it until other measures have been tried. it had worked for another Mac user when corrupt i.e.remove /Logos4/Data/cgrjrfqr.6v7/ResourceManager/ResourceManager.db.
Note that deleting databases does fix issues but I usually recommend renaming them so they can be restored if necessary. There can be severe repercussions from deleting some document databases, but Logos are providing a better alternative for recovery with the My Documents web page.
Quite a number of different resources could not be FOUND at /Users/marknigro/Library/Application Support/Logos4/Data/cgrjrfqr.6v7/ResourceManager/Resources. But prior to that the "Too many open files" message was issued by Mono (I would say .NET in Windows). The final error is likely the ResourceManager database that can't be opened** but there is no indication it is corrupt. I think there is a systemic error that Logos need to look at.
I asked a Logos staff member in another posting http://community.logos.com/forums/p/60582/430571.aspx#430571 if, generally, deleting databases was a valid solution option.
The Firefox add-in KSFJ found has the option to do a database integrity check — which is an action I would start with always. Things like deleting databases are obviously last ditch actions.
The issue with that Firefox tool is it has too much functionality — too easy for an average person to go in there and cause havoc. What I was thinking of is something along the lines of a read-only tool (command line and/or GUI) which could be pointed to a Logos 5 data folder and do an integrity check of all databases. As a 'check off' test to find issues and with the goal to avoid situations of people having to do a complete new data install (download + index).
The thing I am trying to get to the bottom of/understand is the root cause of the crashes I (and others) are getting. When I have a crash where not even the OS X crash report dialog comes up, Logos 5 just cuts out, that is not good.
Like you I also thing there is something fundamental happening — I also got the 'Too many open files' crash but no way could it be said that on the UI that I had too many files/resources open.
What I was thinking of is something along the lines of a read-only tool (command line and/or GUI) which could be pointed to a Logos 5 data folder and do an integrity check of all databases.
We have recommended users to download and run Bitsadmin with success. A simple tool for databases would be useful, but Logos would have to make it available or recommend it.
Things like deleting databases are obviously last ditch actions.
But actions that have been recommended by Logos, and subsequently adopted by others (but one result was catastrophic and a user lost all their Notes!).
