NEW CRASH: 5.2b beta 5
I had a similar crash here
http://community.logos.com/forums/t/86532.aspx
that was a result of Text Comparison and running "Gen-Rev" from Home Page. This one was attributed to trying to do a lot of work in a bunch of panes that open from the Home Page.
Now, I got a bunch of Sermon resources updated, so I wanted to see what had been added to the Sermons section. So I JUST opened Passage Guide, typed "Gen-Rev", and got this crash. Verbum had only been opened for about 10 minutes. This was just running PG:
Comments
-
To allow this to work, create a custom guide that only has the Sermons section.
The current version of Logos does not support running a full PG on the entire Bible, sorry.
0 -
Bradley Grainger (Logos) said:
To allow this to work, create a custom guide that only has the Sermons section.
FYI I Had all the sections closed so the only thing running was sermons.
But your idea does not work either, I created a Guide with only a Sermons section, that too crashes (you can see it partially in the upper left corner):
0 -
Don Awalt said:
I created a Guide with only a Sermons section, that too crashes
This works fine for me. You may want to post logs of just opening Logos and running that new guide.
EDIT: Note though that I'm testing with Logos 5.2b Beta 5.
0 -
I am also on Beta 5, here is the clue - after seeing your post Randy, I went back and tried it - twice with my existing custom passage guide, it ran with no crashes. But then I tried this - I started Verbum, created a custom passage guide, then ran it - it crashes every time so far! You have to start, create a guide, then run Gen-Rev. Here are my logs:
0 -
Don Awalt said:
You have to start, create a guide, then run Gen-Rev.
I've tried these steps, and it worked fine on my machine. I looked at your logs, and it's pretty clear that you're running out of memory:
Error ID: 8037
Error detail: OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.So, it makes sense that you can open the existing one because the data has been generated. As for why you're running out of memory, do you have a lot of background applications running? It might be good to run Task Manager and monitor the memory usage before and during the running of the Guide.
0 -
I couldn't reproduce this either using Logos.exe with Verbum set to either yes or no. I assume Verbum.exe would be the same?
I didn't think an app would normally run out of memory because of the memory use of other applications except under extreme conditions??? Windows usually manages that pretty well. Most of the time it's internal for 32 bit apps or possibly running out of disk space or other resource. Does it work for smaller ranges? Or can the crash be isolated to a certain range?
EDIT: I note Don's log files show he has plenty of available RAM and disk space. More than my system and I have a hard time maxing it out.
0 -
I have 32GB on this computer, and Verbum does not get above 1 GB in this test. I usually have about 5 GB in use, so plenty of memory is available. That doesn't mean that Verbum is not using up what it needs somehow.
0 -
Dylan Rondeau said:
I've tried these steps, and it worked fine on my machine
Dylan did you try it with Verbum beta or Logos?
0 -
Randy W. Sims said:I couldn't reproduce this either using Logos.exe with Verbum set to either yes or no. I assume Verbum.exe would be the same?
Verbum.exe is a totally different executable than running this with Logos.exe and Verbum set to yes. It might be good if someone could try and duplicate this with Verbum.exe. Run it - creat a custom guide with just Sermons - close the template - Run the custom Passage guide for Gen-Rev.
0 -
Don Awalt said:
Dylan did you try it with Verbum beta or Logos?
Verbum Beta 5. Start app, create custom Guide (Sermons only), run on Gen-Rev. No crash, and loaded in ~1 second.
I'm not sure why you're running out of memory. [:(] I did notice that your logs have a lot (10,000 lines?!) of Temporary File logs that mine don't:
[quote]
2014-07-16 11:39:28.3801 7 Info TemporaryFileSearchResultReader Creating temporary file for search hits at 'C:\Users\AWALT\AppData\Local\Temp\tmp791.tmp'.
2014-07-16 11:39:28.3811 7 Info TemporaryFileSearchResultReader Wrote 1 hits from 1 results (0.00 MB) in 00:00:00.0001462.I don't know what's causing that and it could be related. Maybe try clearing out C:\Users\AWALT\AppData\Local\Temp\ and re-running the Guide?
0 -
Dylan Rondeau said:
Maybe try clearing out C:\Users\AWALT\AppData\Local\Temp\ and re-running the Guide?
I keep that cleaned out, I did delete everything (4 files stayed in there because they were open), ran it again - crashed within about 3 minutes.
0 -
Oops here are the logs in case they show something else:
0 -
What is the conclusion on this - is it to be filed as a bug, is there additional troubleshooting needed, etc.? Thanks!
0 -
Someone at Logos ought to be able to answer this or narrow it down. My guess is it is one of: a) a corrupt resource; b) a corrupt DB; c) a bug in the indexing/tagging; or d) you have many more resources than either Dylan or I (~10k) tested with. I don't know how to narrow this down.
I do think it odd that it seems to have created around 5300 temp files on your system whereas it only created about 180 on mine. (I also think it extremely odd that it's creating so many small temp files at all. Seems inefficient, but that's just backseat speculation.)
0 -
Don: I suggest you call tech support and have them connect to your computer remotely (if they are willing to look at a beta).
It would help Logos as much as it helps you.
0 -
It seems like a bug, but we'll have difficulty solving it unless we can get a consistent repro.
I ran a "Gen-Rev" Passage Guide (Sermons only) against all resources available for Logos. My system logged the creation of hundreds of temp files (like Don's), but didn't even come close to running out of memory. (Maximum usage was about 600MB.) So I'm still not sure what is causing this.
0 -
Maybe I'm stating the obvious, but the quickest way is for tech support to get on Don's machine. It could be something idiosyncratic about the HDD/SSD and the driver, or a wider issue.
And wondering ALOUD if beta versions have debug builds as well as hashes to ensure program integrity and easier troubleshooting.
0 -
Lee said:
the quickest way is for tech support to get on Don's machine
We don't offer phone support for beta releases; if Don calls in, they'll very likely refer him to the forums.
0 -
Yes, I figured that might be the case.
But isn't Logos the least bit curious? It would help Logos as much as it helps Don. [:)]
0 -
Don, is this your only Logos install? Do you have another desktop or laptop with Logos you can test this on? I don't expect it would crash but it would eliminate any setting or user data interaction (which I wouldn't expect to exist); the fault could more likely be localized to that one particular install.
0 -
could it be possible that we are encountering a memory fault at an address that is rarely used?
Windows 8 (and 7 if I remember correctly) has a memory test tool.
Additionally one could run prime95 just as a sanity check that its Logos and not an ailing piece of hardware.L2 lvl4 (...) WORDsearch, all the way through L10,
0 -
I ran this test on my other laptop, and it ran fine. So I thought I wonder if the index is corrupted. So I started a Rebuild Index. It only ran for about 3 minutes and then it ended. I have attached the index log (there was no crash or anything), you can see it says the index ended prematurely:
2014-07-17 19:09:26.3241 13 Info BibleIndex (0ms) Attempting to replace index 'C:\Users\AWALT\AppData\Local\Verbum\Data\ds5emrgk.0lc\BibleIndex/index' with new index 'C:\Users\AWALT\AppData\Local\Verbum\Data\ds5emrgk.0lc\BibleIndex/index-build'.
2014-07-17 19:09:26.3511 13 Info BibleIndex Library indexing canceled, failed, or ran out of storage space; deleting temporary files.Does this make any sense?
I have restarted and the Rebuild index has restarted. We will see how far it gets.
0 -
Congratulations, you have been "entrusted with a mystery". [:)]
0 -
Well I finished the complete reindex and ran the test again, it crashes in not even a minute. No way memory is used up that quickly (and it has never even been close when I have watched Perf Mon in the past).
ANy idea what to try, it seems like something is corrupted - a catalog to delete etc.?
0 -
Sorry to sound like a broken record. Best thing now is for tech support to consider the wider interests, and get on your machine to track down this SHOWSTOPPER bug.
0 -
Tried deleting the catalog.db and journal, same thing.
0 -
If Logos does not want to look into this case more closely, Don maybe you should just get out of the beta channel for now.
0 -
I have now tried on two other machines, one the Gen-Rev worked, the other it crashed. So it's not just unique to one computer.
Of the two of three that crashed, they were older installs that have been through lots of upgrades. The one that did not crash is newer. So my next attempt if to take one of the laptops that crashed, and I am reinstalling Verbum and will then see if it works. If so, this will be the second time (first was a year or two ago as I recall) that something gets so corrupted you just have to reinstall everything. Stay tuned.
0 -
Sorry you had to do a re-install. If it works it seems like you narrowed it down to a resource problem, having already rebuilt the indices. My guess is the code is encountering something unexpected in a version of a resource or the index created from a resource that's causing it to eat resources (maybe infinite recursion/loop?). "Update Resources" may fix the other crashing system. If it does, would love to see the logs from the update. Just another WAG.
0 -
Seeing if I can duplicate the error on my machine.
Logos is on a basically empty 256gb ssd, with 22gb ddr3, and a fx8350 processor. Should be sufficient.L2 lvl4 (...) WORDsearch, all the way through L10,
0 -
<sigh>. This stinks. Reinstalled, reindex, Gen-Rev, crashes in about 10 seconds.
0 -
My guesses keep hitting dirt. What's the same about the ones that don't work? What's different about the one machine you have where it does work? Did you log on with the same account? Are they all Windows and the same Windows version? Are they all running Verbum and at the same version? Are they all online and synced? Same language settings, etc? I'd feel better if they were all crashing; at least there would be some consistency.
With it failing on two machines and one with a fresh install it seems somehow tied to Don's account. If I were Logos, with Don's permission, I would open up a fresh box of Logos, log in under his account and try to repro it in house.
0 -
Did you log on with the same account? YES
Are they all Windows and the same Windows version? YES
Are they all running Verbum and at the same version? YES
Are they all online and synced? YES
No one from Logos has replied for awhile. Despite this being a beta forum, unless they are working on it somehow I don't think they see it as important. If when 5.2b goes gold and it still crashes, I uninstall it because I won't trust what else it might be corrupting on my system.
0 -
Don Awalt said:
No one from Logos has replied for awhile. Despite this being a beta forum, unless they are working on it somehow I don't think they see it as important.
Don, I'd like to reassure you that we do care about your issue (in fact, you've already had our head developer reply three times in this thread!). I've been attempting to figure out what's going on and reproduce this, in addition to my other responsibilities.
Unfortunately, I'm (personally) out of ideas, as Bradley and I haven't been able to reproduce it. I've created a case for the developers to look into, hopefully someone can figure it out.
Randy's suggestion to try having a dev log in under your account seems like it might be useful, but I'm not sure if that's something we (company-wise) do. I'll make a note on the case to see if that (or something similar) is an option. Sorry again for the delay in responding.
0 -
Thank you Dylan for the response, it means a lot. It gets frustrating when you think you are alone on an issue.
Over the weekend, I plan to install Logos version of the latest bet and try that. I'll post here what I find. Maybe it's Verbum-specific....
0 -
Don Awalt said:
Over the weekend, I plan to install Logos version of the latest bet and try that. I'll post here what I find. Maybe it's Verbum-specific....
We've figured out what causes the crash. There is no workaround (other than searching on a smaller range, e.g., Gen-Deut, Josh-Job, etc.,); reinstalling won't help.
0 -
The crash appears to be intermittent because the .NET Framework needs to find 150MB of contiguous memory in the process' virtual address space. (If it can't, it crashes.)
In a 32-bit process, address space is extremely limited so it's likely (but not guaranteed) that this will crash.
0 -
Wow great job! Is it Logos.exe and Verbum.exe?
I seem to remember reading there are some utilities that will reorganize memory to make larger contiguous space available. I wonder if that would help.
0 -
Don Awalt said:
I seem to remember reading there are some utilities that will reorganize memory to make larger contiguous space available. I wonder if that would help.
No. Don't bother with them; they are useless and won't do anything at all to help in this case.
0 -
Bradley Grainger (Logos) said:
We've figured out what causes the crash. There is no workaround (other than searching on a smaller range, e.g., Gen-Deut, Josh-Job, etc.,); reinstalling won't help.
(1) 150MB of contiguous memory sounds very limiting. Is there a workaround programmatically, e.g. chunk up the search internally?
(2) Why does it crash on a machine with 32GB RAM, but not on many other machines?
(3) Why should it crash at all? Shouldn't there be a graceful exit? If nothing can be done, shouldn't the user be restricted from performing such an action?
0 -
Lee said:
(1) 150MB of contiguous memory sounds very limiting.
Agree. This seems very onerous from .NET. I wonder if this is a fixed number or, more likely, a number imposed on those with larger sermon libraries?
Lee said:Is there a workaround programmatically, e.g. chunk up the search internally?
I'm sure there is. I've read many posts on these forums and on the Logos code blog. I've been programming for many years and these guys make me feel like an amateur. Now that they've isolated the problem, I've every confidence they will find a solution.
Lee said:(2) Why does it crash on a machine with 32GB RAM, but not on many other machines?
From your posts, I know that you are aware that 32 bit apps only have access to a small part of that memory space. I assume that the problem is likely related to those with larger libraries, specifically those with large sermon libraries.
Lee said:(3) Why should it crash at all? Shouldn't there be a graceful exit? If nothing can be done, shouldn't the user be restricted from performing such an action?
Agreed. Catching exceptions is something that Logos seems to overlook sometimes. But I have to admit that expecting an out of memory error from this bit of code is very unexpected and I don't think I would have expected it either.
0 -
- Yes, this is a bug that we hope to fix in an upcoming release.
- On modern operating systems (by which I mean Windows 95 and later), an "out of memory" error has nothing to do with the amount of RAM installed in the computer. Programs use "virtual memory", which the OS maps to physical RAM (and swaps in and out from disk if RAM is unavailable). Running out of memory means you've used up your virtual address space. For a 32-bit process, this address space is typically limited to 2 or 4GB; due to the overhead of the .NET Framework and other components, Logos 5 can typically use about 1GB of memory before it crashes. A 64-bit process has a limit of 8TB of memory, so moving to 64-bit solves a lot of these problems. See http://blogs.msdn.com/b/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx for more technical details.
- Because recovering from an OutOfMemoryException is extremely difficult. The program is literally at a place where allocating any memory at all may fail, but most recovery actions need to allocate memory. Want to show the user a dialog saying there was a problem? Sorry, that requires memory. Want to save current state to disk? Sorry, that requires memory. Want to log an error? Sorry, that requires memory.
The best way to solve these kind of problems is to move to a multi-process architecture (like Chrome), where you can just let one of the processes crash and the rest of the program carries on. This typically requires a multi-process design upfront, and is generally very difficult to add to an existing program. (I think Firefox has been working on switching to a multi-process model for over three years.)
0 -
Which decade do you plan on updating the program to 64-bit? [|-)]
0 -
Why does it crash on a machine with 32GB RAM, but not on many other machines?
-- The irony is that Don's machine souped up with 32GB crashes, while other machines don't (even Don's other machine).
I sure do sympathize that you are struggling with the .NET framework.
I don't know about the intricacies of moving up to 64-bit, but I hope that Logos is able to overcome the 1GB ceiling.
0 -
Thanks for the explanation Bradley. It does make one wonder about 64 bit, as libraries get bigger these kinds of issues are going to happen more and more, right? I suspect you can see the time when an effective limit of 1 GB for Logos will be a real issue now that libraries, datasets, tools, etc. are growing so.
0 -
Bradley Grainger (Logos) said:
Yes, this is a bug that we hope to fix in an upcoming release.
That upcoming release is 5.2b Beta 6, which has just been shipped. (I'm currently watching the Verbum ship process, so give it a few minutes [:)])
0 -
Mr. Simple said:
Which decade do you plan on updating the program to 64-bit?
0 -
Lee said:
I don't know about the intricacies of moving up to 64-bit, but I hope that Logos is able to overcome the 1GB ceiling.
0 -
Bradley Grainger (Logos) said:
Thanks for the reply even though my question was framed in a snarky manner, ... rubbing is racing as they say in NASCAR
0
