Crash on Update Active Layout

Comments
-
Looks like a problem with that layout. You could manually rename an "Application Closed" layout that represents your "active" and then try Update Active after making changes.
Dave
===Windows 11 & Android 13
0 -
0
-
Pam Larson said:
Laptop only has 8GB RAM - not enough for 10K resources?
8 GB of ram should be sufficient... unless you had all 10K resources open at once. [:D]
Pam Larson said:It happens regularly with a variety of layouts. Logs always show a "system out of memory exception" when it happens.
The issue isn't likely the number of resources... but what features are you using in the layouts? Any guides? If so, which ones? What else?
macOS, iOS & iPadOS |Logs| Install
Choose Truth Over Tribe | Become a Joyful Outsider!0 -
0
-
Pam Larson said:
Thanks, Dave. It happens regularly with a variety of layouts. Logs always show a "system out of memory exception" when it happens. Maybe a RAM problem? Laptop only has 8GB RAM - not enough for 10K resources?
Can you post a screenshot of one of the layouts it has crashed on?
0 -
Added: When the crash happened, Logos was not indexing or downloading anything.0 -
Sorry Pam I didn't see that link earlier. Looking at it now, the layout is a bit. . .hefty. Logos is a 32bit application and we will run out of memory with too many files being open. I would close anything you don't need in order to reduce the amount of tabs you have open.
0 -
0
-
Hmm, sorry Pam. Can you give us a call at your earliest convenience? We are open 6-6 (PST) Monday through Saturday. The phone number is 800-875-6467.
0 -
I've been investigating this problem and have found a memory leak in the Cited By panel for users who have lots of collections. My recommendation (while we investigate this further) would be to rebuild frequently-used layouts without the Cited By tool open.
0 -
Tommy Ball said:
Looking at it now, the layout is a bit. . .hefty. Logos is a 32bit application and we will run out of memory with too many files being open. I would close anything you don't need in order to reduce the amount of tabs you have open.
Could you please elaborate on your statement with the idea of providing some guidance for layout design? Below are questions that come to mind, are there some you can comment on?
- How many tab/open files risk a "run out of memory" situation?
- What variables have the greatest effect on the memory used, e.g. the size of the resource files?
- What is the effect on memory used in multiple windows on multiple monitors?
- Should search tabs and other open program features be included in the tab count? (I'm avoided "cited by" per Bradley's post.)
I have had some layouts with a few dozen resources open that crashed Logos and would not allow restart the program unless I did so with a blank layout. Other layouts with a similar number of resources didn't seem to have a problem.
Thanks in advance,
Scott
0 -
I had crashes this morning with 3 different layouts. Only one of them had the Cited By panel open.Bradley Grainger (Logos) said:I've been investigating this problem and have found a memory leak in the Cited By panel for users who have lots of collections. My recommendation (while we investigate this further) would be to rebuild frequently-used layouts without the Cited By tool open.
One suggestion tech support had when I called Friday was not to check off Parallel Resources on large collections, as these burn up memory. I went through my collections over the weekend and removed all the Parallel Resource check marks so that wasn't the problem this morning.
Wondering if having a lot of Visual Filters active is a problem?0 -
Just so we're clear, L5 easily handles over a hundred resources open, most linked, along with multiple CitedBys also open and linked, with multiple collections per CitedBy. Coordinated across 5 windows. L5 is impressive.
Most likely a glitch. I usually don't 'defend' the competition but Logos staff under-rating Logos prowess seemed unfair.
Ok, back to Pam's struggle.
"If myth is ideology in narrative form, then scholarship is myth with footnotes." B. Lincolm 1999.
0 -
Scott S said:
- How many tab/open files risk a "run out of memory" situation?
- What variables have the greatest effect on the memory used, e.g. the size of the resource files?
- What is the effect on memory used in multiple windows on multiple monitors?
- Should search tabs and other open program features be included in the tab count? (I'm avoided "cited by" per Bradley's post.)
- It can really depend on the type of tab; some use more memory than others. In general, there isn't a hard limit on the number of tabs you can open. However, each tab will use some memory, so eventually you will run out of memory if you're opening hundreds of tabs at once.
- Again, "it depends". A resource just by itself doesn't use much memory; a resource showing hundreds of thousands of visual filter hits will use much more memory. A notes document with hundreds of notes doesn't use much memory; a notes document with tens of thousands of notes will use more. Unfortunately, there's not an easy general rule-of-thumb I can give; a lot depends on the implementation details. In the OP's case, we discovered (due to this crash report) that the Cited By panel is using a huge amount of memory in a very particular scenario. This was unintentional, and we will be fixing it.
- Using multiple windows on multiple monitors has a negligible effect on memory usage.
- Yes; all tabs count towards memory usage.
Scott S said:I have had some layouts with a few dozen resources open that crashed Logos
This could be due to a completely different issue. If you create a new thread and post logs, we can offer advice specific to your situation (and hopefully fix any underlying bugs that are causing the crash).
In general, we don't want to "punish" you for heavy use of the program. We don't ever want to crash with an OutOfMemoryException. However, in certain cases, there can be situations that the original programmer didn't account for. For example, in the OP's case, the Cited By panel is incorrectly using a lot of memory when there are a lot of collections (implicit or explicit). This is a bug in the application that we intend to fix.
0 -
Pam Larson said:
Only one of them had the Cited By panel open. One suggestion tech support had when I called Friday was not to check off Parallel Resources on large collections, as these burn up memory. I went through my collections over the weekend and removed all the Parallel Resource check marks so that wasn't the problem this morning. Wondering if having a lot of Visual Filters active is a problem?
The memory leak that I found after trying to reproduce the scenario reported in your logs was quite insidious. If you've ever had the Cited By panel open at all (during the lifetime of the application), it probably has leaked some memory and has contributed to the crash.
I'd have to check on it, but I don't think checking "Show in parallel resources" on a collection would use additional memory. It might slow Logos 5 down, so it could be a performance improvement to uncheck it for non-parallel collections, but I'm not aware of it being a contributor to high memory usage.
Having a lot of visual filters active can use up memory. There were some lines in your log file that potentially indicated that an "expensive" visual filter was being run. However, this tends to indicate that the visual filter (or search) is trading memory usage for increased runtime (so it shouldn't contribute to the crash, but may make Logos 5 run more slowly). If you have a visual filter that uses a very broad wildcard term (e.g., anything involving "*"), you should consider disabling it to see if Logos 5 runs more smoothly without it.
0 -
Denise said:
along with multiple CitedBys also open and linked
Thanks for the vote of confidence!
In most cases, having Cited By open isn't a problem. However, if you do have thousands of collections (created explicitly through the Resource Collections panel, or created implicitly through tagging), Cited By can use much more memory than we ever intended. If it's opened and closed repeatedly, or navigated to many different references, it can leak memory that will cause an OutOfMemoryException and crash the app.
This is a bug in Logos 5 that we plan to fix, perhaps in the next release or possibly in a 5.2 Service Release.
0 -
Bradley,
Thanks for the interesting reply.
Bradley Grainger (Logos) said:Scott S said:I have had some layouts with a few dozen resources open that crashed Logos
This could be due to a completely different issue. If you create a new thread and post logs, we can offer advice specific to your situation (and hopefully fix any underlying bugs that are causing the crash).
I didn't report the earlier crashes due to time constraints (and one of Dave Hooton's tips allowed me to quickly recover).
I may have saved the layouts that caused the crash and if I can duplicate the problem, I will document and report it. Is there any concern about repeating crashes, might that damage my Logos installation?
Bradley Grainger (Logos) said:we don't want to "punish" you for heavy use of the program
I appreciate that, because when studying some issues I love having dozens of tabs open. It is like sitting at a big table with piles of books open to just the right pages.
Thanks again,
Scott
0 -
I had several different morphological filters turned on but not using "*" , just "??" e.g. "@N???C" for Hebrew nouns. I turned off all the morph filters in trying to free up memory. Now I can't get them back. They no longer show up as options when I click the Visual Filters icon, in any of my Greek or Hebrew resources. :-(Bradley Grainger (Logos) said:Having a lot of visual filters active can use up memory. There were some lines in your log file that potentially indicated that an "expensive" visual filter was being run. However, this tends to indicate that the visual filter (or search) is trading memory usage for increased runtime (so it shouldn't contribute to the crash, but may make Logos 5 run more slowly). If you have a visual filter that uses a very broad wildcard term (e.g., anything involving "*"), you should consider disabling it to see if Logos 5 runs more smoothly without it.
0 -
Pam Larson said:
I had several different morphological filters turned on but not using "*" , just "??" e.g. "@N???C" for Hebrew nouns.
Terms with ? are not "a very broad wildcard term" (quoting Bradley) and morphological filters routinely use them as opposed to the broad * wildcard.
Pam Larson said:Now I can't get them back.
That is unusual. Are they still visible in the Documents menu?
Dave
===Windows 11 & Android 13
0 -
Yes, they are all still showing up in Documents. I restarted Logos; that didn't help. I restarted my computer; that didn't help.Dave Hooton said:That is unusual. Are they still visible in the Documents menu?
I tried creating a couple of simple new morph filters, one Greek and one Hebrew, and they're not showing up in the resources either.0 -
Scott S said:
Is there any concern about repeating crashes, might that damage my Logos installation?
Crashing the program should not damage local documents and settings.
0 -
Pam Larson said:
Yes, they are all still showing up in Documents.
Has their scope changed i.e. are they showing the resources/collections you want? When you run them as a Search do they produce results?
Is the formatting valid?
Dave
===Windows 11 & Android 13
0 -
Hard to do much right now - Logos says first time indexing is underway. Not sure why that's happening.0 -
Pam Larson said:
Logos says first time indexing is underway.
Could be an automatic re-index following an error but it is hard to know without logs. Enable logging ASAP and if the problem continues after current indexing ceases then uipload the log file folder.
Dave
===Windows 11 & Android 13
0 -
0
-
Almost certainly - I'm glad Filters are working again.
Dave
===Windows 11 & Android 13
0