5.1 RC-3: CRASH: Slow scrolling/paging in Library leads to crash
Running on Windows 7 on a very fast machine. See my machine specs in link in my signature.
When I open the Library in a floating window to full screen and simply page down through it (holding my finger on the Page Down key), the scrolling is slow and jerky, not smooth and quick as I'd expect. I sometimes have to wait up to 5 or 6 seconds between pages.
In the last couple of sessions when I've tried it, it starts out taking about 1 second per page and then gets slower and slower to the point where it crashes.
Log files attached: 3036.LogosCrash L5.1RC3 20130626b.zip
Note: this is probably the same bug as the one I just reported, as now that I think of it I was fooling around with this page down thing trying to see how slow it was just before I left Logos alone for a while, and when I came back to it, it was crashed.
Comments
-
I can reproduce this, in both Reading View and with library in an ordinary tab. The exact number of resources scrolled through varies between approximately 3,000 and 4,000, by which time memory usage from the Logos process hits around 1.2Gb.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Yay, thankful for a reproducible case. These memory exception crashes can sometimes be really hard to nail down, and Logos often can't reproduce them in house and does nothing about them.
0 -
Rosie Perera said:
In the last couple of sessions when I've tried it, it starts out taking about 1 second per page and then gets slower and slower to the point where it crashes.
I complained about this slowness way back in 4.6a, but I didn't try it enough to cause a crash. The library was clearly slower at that point than previous versions. It was too slow for me to bother using it that way enough to get to the point you got.
MacBook Pro (2019), ThinkPad E540
0 -
Thanks for reporting this crash; I can reproduce the problem.
0 -
Bradley Grainger (Logos) said:
Thanks for reporting this crash; I can reproduce the problem.
Hallelujah! Hope it turns out to be an easy fix. Also I hope you manage to improve the performance of scrolling in the Library when you find out where the memory leak was that was causing this crash.
0 -
Bradley Grainger (Logos) said:
Thanks for reporting this crash; I can reproduce the problem.
I posted in haste. What I can actually reproduce is increased memory usage, but never a crash. And I can only repro this when holding down the PgDn key and scrolling non-stop; this would be a nice scenario to support better, but doesn't seem critical at this point.
0 -
Bradley Grainger (Logos) said:Bradley Grainger (Logos) said:
Thanks for reporting this crash; I can reproduce the problem.
I posted in haste. What I can actually reproduce is increased memory usage, but never a crash. And I can only repro this when holding down the PgDn key and scrolling non-stop; this would be a nice scenario to support better, but doesn't seem critical at this point.
But fix the crash please. I know you can't reproduce it yet, but two of us here can, so I think you ought to try harder to make it happen. How many books do you have in your Library? Mark and I have a lot (I've got 10,766), and that might be key to reproducing.
Is there any more in-depth logging we could enable that might help detect why it's crashing?
While I admit this has only happened to me when I made a concerted effort, and perhaps it's not worth making a concerted effort to fix it, my years as a developer mean I still don't like any easy dismissal of crashing bugs.
0 -
Bradley Grainger (Logos) said:
What I can actually reproduce is increased memory usage, but never a crash. And I can only repro this when holding down the PgDn key and scrolling non-stop; this would be a nice scenario to support better, but doesn't seem critical at this point.
I can reproduce this crash. This looks like a problem with garbage collection. I notice when using the mouse to page down the scroll bar that memory increases in roughly 10MB increments the first couple of times I page down and the the memory is reclaimed. If I hold down the mouse in the scroll bar it increases a lot further but there is still time for the app to reclaim the memory before it gets over ~500MB. However, when using the page down, the app never gets enough time to reclaim the memory. Can you try adding a handler for key event to reclaim memory periodically? This does not look like a memory leak, just a simple issue of giving the app time to reclaim memory.
The jerkiness is caused during garbage collection as the app waits on memory to be freed.
0 -
Randy W. Sims (Shayne) said:
This looks like a problem with garbage collection. ... Can you try adding a handler for key event to reclaim memory periodically?
Excellent analysis.
The short answer is: no. (The long answer is: not without a complete rewrite.) The WPF GridView is holding references to these objects, and is not releasing them during scrolling. (So forcing garbage collection won't do anything, because the objects aren't technically garbage yet.)
We've added a small fix to reduce memory usage (probably shipping in a 5.1 Service Release); in the meantime, don't press and hold down Page Down.
There's no reason that I can think of that this would be a new bug in 5.1; it's likely to have existing since 5.0 (or perhaps even 4.0 if WPF 4 didn't change the behaviour significantly).
0
