Bug: 4.2a SR-1: Reproducible Crash when creating a handout (memory leak?)

This bug was original reported here. I have re-created the crash on my own computer, suggesting an underlying Logos bug or common faulty resource. In my case, all I did was run a passage guide on John 8:31-59 then create a handout from the passage guide.

6557.Logos4.log

5327.Logos4Crash.txt

4341.Report.wer.txt

During the Passage Guide, Logos4.exe memory usage went up to more than 950Mb. If I edit the handout (Logos crashes before, and sometimes after I try and do this) whilst the passage guide still displays, memory usage goes to up 1.2Gb.

I think this high memory usage is caused by the large family trees that Logos tries to insert.

There's also a noticeable memory leak with handouts. If I'm editing a handout memory usage of the Logos4.exe process can shoot up several hundred Mb. But this memory is not always released when I close the handout.

Find more posts tagged with

Comments

David Wilson

Thanks Mark: Just a note if I may: the issue is not new to 4.2a SR-1, but was first notced in 4.2 prior to the release of 4.2a (persists in 4.2a SR-1)

(Crash logs etc posted to Logos 4 forum http://community.logos.com/forums/t/30493.aspx starting March 1st)

Melissa Snyder

I'm not able to reproduce the OOM crash going through each of David's steps, with preferred Bible set to NRSV. When I select the 'Classic' theme, the 'Family Tree: Jesus (Mt 1:1-17)' remains below the dotted line and the preview is correct as I page through the handout.

It does take a few seconds for changes to take affect. I'm wondering if the handout is still in process of making a change when something else is clicked.

Mark Barnes

https://community.logos.com/discussion/comment/228034#Comment_228034

Sometimes I have to work harder than others to get the crash, but I can reproduce it pretty easily within a few goes of step 4, below. My steps in creating the crash were:

Passage Guide on John 8:31-59 (Logos memory usage at this point 528kb)
Click 'edit' next to John 8:31-59 handout in passage Guide (memory now at 682kb)
Switch to Classic View (memory now at 935kb)
Move around the elements of the passage guide. In particular, move the family trees into the visible area (memory usage peaks at 1.1Gb)
CRASH!

The crucial point is the enormous amount of memory that the handouts are consuming in this configuration. That can't be by design.

David Wilson

https://community.logos.com/discussion/comment/228034#Comment_228034

It does take a few seconds for changes to take affect. I'm wondering if the handout is still in process of making a change when something else is clicked.

Good thought : However, I was deliberately letting the software take as long as it needed. It did indeed take quite a few seconds to decide where to put the dvision between the content items. It took perhaps ten seconds beyond what appeared to be a final decision point with the dividing line to apparently reconsider and decide on even more content, beyond the capacity of the pages to accomodate. I took a hands off approach and went to do something else to avoid clicking anything while it was still processing.

Definitely not an easy one to reproduce [:^)]

Per Mark's comment on memory useage: the first crash occurred on my main machine while it was relatively lightly loaded (little else going on), and the system has 8GB RAM and plenty of temp space available on local HDs beyond that. To get an out of memory error it must have gone WAY beyond the 1+ GB Mark saw.

Melissa Snyder

https://community.logos.com/discussion/comment/228085#Comment_228085

The crucial point is the enormous amount of memory that the handouts are consuming in this configuration. That can't be by design.

Improvements to memory usage when working in Handouts were made about a year ago, although, an occasional OutOfMemory exception may still occur. Additional Handout improvements are coming. I will add a link to this thread to the case.

Mark Barnes

https://community.logos.com/discussion/comment/228126#Comment_228126

To get an out of memory error it must have gone WAY beyond the 1+ GB Mark saw.

I have 6Gb RAM, myself. But OOM errors need not be caused by your entire RAM being used up. 32-bit applications can't use more than 2Gb RAM each as an absolute limit. Even then the real limit will often be much lower.

David Wilson

https://community.logos.com/discussion/comment/228138#Comment_228138

I will add a link to this thread to the case

Many thanks Melissa.

Quick Links

Recent Posts
Activity
Unanswered