NEW CRASH: 5.2b beta 5
Comments
-
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 -
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 -
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 -
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 -
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 -
(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?
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.
(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.
(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 -
-
Which decade do you plan on updating the program to 64-bit?
0 -
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 -
Which decade do you plan on updating the program to 64-bit?
Thanks for the reply even though my question was framed in a snarky manner, ... rubbing is racing as they say in NASCAR
0
