I could not quite my logos 5 mac.
I'm attaching my log and please advice me.
Thanks.
6708.LogosLogs.josephbaik.20140217-193700.zip
Logos 5.2 SR-5 is installed (on OS X 10.9.1), which includes crash fix after sleep => Logos Crash on Exit that is linked from Logos 5.2 SR-5 release notes
Noticed Logos diagnostic logging is not enabled. Description in other thread => Could not able to quit (Logos 5 mac) seems similar to => Hang that has replies by Logos => http://community.logos.com/forums/p/79690/557916.aspx#557916
By Design, Logos 5 attempts to sync changes to Logos servers when quiting. Before shutting down OS X, recommend quit of Logos 5 to allow Logos 5 time to synchronize.
LogosError.log shows many timeouts when attempting to connect to Logos servers, which could be the cause for needing to force quit.
By the way, the same log files were previously posted in other thread => http://community.logos.com/forums/p/81349/569231.aspx#569231
Note: multiple threads about the same topic can be conversationally challenging.
Keep Smiling [:)]
I have been having regular freezes for a week or more--however long since the last software update--I think. Sometimes I can go half a day. Sometimes maybe 10 minutes--as in the attached log. Any help would be appreciated as I am presently using Logos about 16 hours a day. That turns out to be quite a few crashes, lost tabs, and lost locations.
622423.Logos.log
and a second log...
0285.Logos.log
Note: my computer keeps working fine...just Logos freezes.
It would help if you told us the computer time of the freeze along with two logs as above.
Presumably the time I notice the freeze may possibly be a different time than the last time indicated in the log?
I will attempt to note that in the future.
I am also now trying a complete new re-index--just in case--which I hadn't tried yet.
Thanks
Each action logged has a time to compare with your time, so we can see what was happening.
I don't know how much time differential you are looking for. I do not know how to simultaneously watch logs and know what events Logos is performing to compare times. Perhaps there is a way?
What I do know is that when Logos crashes, I dash out and check the log. The last event in the log is within 2-3 real computer-time minutes of the freeze--if that helps. I will try to verify this with greater accuracy a few times. Unfortunately [:O] Logos has not crashed after several hours now, since completing a full re-index. Hmmmmmm. Fortunately! [:)]
I don't know how much time differential you are looking for.
I am simply wanting you to look at your computer's clock and note the time that Logos "hangs" or "freezes" e.g. 5:38 pm, because you are the only one that can notice a hang or when it becomes unresponsive. If the program crashes we get a log with all the details. So keep logging until the freeze finishes and then upload the logs.
No more freezes. Perhaps a total re-index fixed it? Or maybe the recent update? Who knows!
But I am a happy camper!
Note to self: Remember to try re-indexing long before suffering 2 weeks of freeze-ups!
On the assumption that GL's problems were related to the index, wouldn't it be nice if the Logos executable is able to jump out of an unexpected condition after a timeout, and rebuild automagically?
If it were that simple; but there is nothing "nice" about a complete index rebuild when it still freezes after several hours! Note that Logos 5.2a will have a automatic fix for corrupt databases because Logos has observed the amount of manual fixes over the last few years and has taken steps to ensure that fixing a single database won't have disastrous repercussions for related databases.
On the assumption that GL's problems were related to the index, wouldn't it be nice if the Logos executable is able to jump out of an unexpected condition after a timeout, and rebuild automagically? If it were that simple; but there is nothing "nice" about a complete index rebuild when it still freezes after several hours! Note that Logos 5.2a will have a automatic fix for corrupt databases because Logos has observed the amount of manual fixes over the last few years and has taken steps to ensure that fixing a single database won't have disastrous repercussions for related databases.
You're absolutely right, Dave. But I was talking about a situation where the freeze occurs because of problems with the index (which was the assumption). In such a case instead of a freeze, there could be routines for timing out and rebuilding. Of course, GL's freeze could have been caused by many other factors, so the assumption may be invalid.
