openlp crashes on windows when displaying images

Bug #1002064 reported by John Cegalis
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenLP
Won't Fix
Low
Unassigned

Bug Description

Windows build 1970. This did not happen in 1964.

I have a group of images and I started looping them. After so long openlp crashes with a windows error. I attached a debug log and cut out the repeats all through the center. In this instance it appears to have taken almost 2 hours. This morning during the church service it only took an hour. Yesterday I had it on 1 image only with no looping (obviously) and it crashed with the windows error. I have never had openlp crash in any way in the last year.

Revision history for this message
John Cegalis (jseagull1) wrote :
Revision history for this message
John Cegalis (jseagull1) wrote :

This is Win7

Changed in openlp:
importance: Undecided → Critical
milestone: none → 1.9.10
tags: added: regression
Revision history for this message
John Cegalis (jseagull1) wrote :

Further testing I displayed a single image in rev 1967 and let it go. Looking at the time it crashed 9 hours later. The debug log was 64 meg and I cut out the middle which was all the same. It crashed 20 minutes before I got up and looked at it. I am now testing 1964.

Revision history for this message
John Cegalis (jseagull1) wrote :
Revision history for this message
John Cegalis (jseagull1) wrote :

I don't want to flood this bug but this is new. rev 1964. It starts out looping with memory usage around 355000. The last I looked before the traceback is was up to 1.2 gig. When I closed the traceback it immediately popped up again. I was running in debug but the log was reset. This all happened in a period of about an hour.

Traceback (most recent call last):
  File "D:\OpenLP_Code\rev-1964\build\pyi.win32\OpenLP\out01-PYZ.pyz\openlp.core.ui.slidecontroller", line 1292, in timerEvent
  File "D:\OpenLP_Code\rev-1964\build\pyi.win32\OpenLP\out01-PYZ.pyz\openlp.core.ui.slidecontroller", line 1176, in onSlideSelectedNext
  File "D:\OpenLP_Code\rev-1964\build\pyi.win32\OpenLP\out01-PYZ.pyz\openlp.core.ui.slidecontroller", line 1100, in slideSelected
  File "D:\OpenLP_Code\rev-1964\build\pyi.win32\OpenLP\out01-PYZ.pyz\openlp.core.ui.maindisplay", line 302, in image
  File "D:\OpenLP_Code\rev-1964\build\pyi.win32\OpenLP\out01-PYZ.pyz\openlp.core.ui.maindisplay", line 310, in displayImage
MemoryError

Revision history for this message
Raoul Snyman (raoul-snyman) wrote :

It looks like there is a memory leak in the remotes plugin. Switch it off and test again.

Revision history for this message
John Cegalis (jseagull1) wrote :

The church computer I use has 3 video cards in it. I use the third video card for stage viewing on Firefox, dragged over to the 3rd display for the rear projector.
I tested looping images on rev1970 without Firefox running or the stageview and it went for 3.5 hours without an issue. I opened Firefox again with stageview and it crashed after a couple hours. Memory usage was up to 1.5 gig when it crashed.
This is as much as I know.

Revision history for this message
Andreas Preikschat (googol-deactivatedaccount) wrote :

Set to Medium, as it does not affect everybody/does not occur under normal conditions. Also it does not seem to be regression.

tags: removed: regression
Changed in openlp:
importance: Critical → Medium
Changed in openlp:
status: New → Confirmed
Changed in openlp:
milestone: 1.9.10 → none
Revision history for this message
John Cegalis (jseagull1) wrote :

On Raoul's request I re-tested this on Win7 2049. I had a group of images cycling every 20 seconds for 7 hours. Memory usage when I shut it down was 1.15 gig and it was working fine but the memory usage was still climbing in that time. The same with above, it started out looping with 355000. I suppose you have to decide if you want to find the memory leak or not.

Revision history for this message
Raoul Snyman (raoul-snyman) wrote :

This seems like a very corner-case bug which few are able to reproduce. I think we should move it to 2.1.

Revision history for this message
Raoul Snyman (raoul-snyman) wrote :

Downgrading this to a low as it is a very corner-case scenario. I've moved it to 2.1.

Changed in openlp:
importance: Medium → Low
milestone: none → 2.1.1
Revision history for this message
Tim Bentley (trb143) wrote :

Marking as wont fix - Please confirm if this is still a problem as 2 years have passed.

Changed in openlp:
milestone: 2.1.1 → none
status: Confirmed → Incomplete
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.