3.1.7 crash on WIndows 11 when OpenLp window is shrunk

JohnLines

On WIndows, since 3.1.7 if we shrink the OpenLP window below some size (with all the panels active) then it crashes.

Also if it crashes and has run PowerPoint then we have to kill Powerpoint via Task Manager (or reboot) before we can use it again.

This does not happen on my Debian Linux version of 3.1.7 - which simply refused to shrink below a certain size.
Unfortunately the system we use at church is the WIndows one.

Our more experienced AV people know to simply avoid doing this during a live service, but we are keen to recruit more people and it would be good to avoid any problems as they are quite visible and deter people from joining the team (even if problems are very rare).

MickWUK

Same problem here. (From a very quick test, 3.1.0 doesn't have this problem).

Debug log file follows (it's small and I couldn't upload it for some reason.

2025-03-16 13:23:14,400 MainThread openlp.core.common.actions WARNING Shortcut "" is removed from "fileExitItem" because another action already uses this shortcut.
2025-03-16 13:23:14,671 MainThread openlp.core.common.actions WARNING Shortcut "" is removed from "settingsConfigureItem" because another action already uses this shortcut.
2025-03-16 13:23:17,321 MainThread openlp.plugins.presentations.lib.impresscontroller WARNING Failed to get COM service manager. Impress Controller has been disabled
2025-03-16 13:23:21,963 MainThread openlp.core.display.webengine ERROR :1 Uncaught ReferenceError: Display is not defined
2025-03-16 13:23:22,149 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,151 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,165 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,166 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,178 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,183 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,194 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,194 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,196 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:23:22,197 MainThread openlp.core.display.webengine ERROR file:///C:/Users/mickw/Downloads/OpenLPPortable/App/OpenLP/core/display/html/reveal.js:1995 Uncaught RangeError: Maximum call stack size exceeded.
2025-03-16 13:26:24,271 Dummy-2 asyncio ERROR Task was destroyed but it is pending!
task: <Task pending name='Task-3' coro=<IocpProactor.accept.<locals>.accept_coro() running at asyncio\windows_events.py:566> wait_for=<_OverlappedFuture cancelled>>

STEPHANVS

Can reproduce also by shrinking the Live panel's html view. If Live panel is not visible, crash is not occurring.

witterholt

I can't reproduce it on Windows 11 24h2. Can you share a video clip showing how to let it crash? Does it also crash in single screen mode? And what is the Windows version that you use?

MickWUK

witterholt
Video showing this... https://youtu.be/RBQCb5ZlsYs

I'm on Win11 24h2 too (OS Build 26 100.3476).

witterholt

MickWUK strange, after seeing the video I still cannot reproduce it here. I also used the lower right corner.

MickWUK

Hmm, yes, odd. Contrary to what I said above, I do get the same crash on 3.1.0 (portable, in that case).

Still, it's not a disaster. So long as we remember not to shrink it too much it's a problem that we can live with.

Maybe this error.log will help?
Windows fatal exception: stack overflow

Thread 0x00002d94 (most recent call first):
File "threading.py", line 327 in wait
File "waitress\task.py", line 71 in handler_thread
File "threading.py", line 982 in run
File "threading.py", line 1045 in _bootstrap_inner
File "threading.py", line 1002 in _bootstrap

Thread 0x0000574c (most recent call first):
File "threading.py", line 327 in wait
File "waitress\task.py", line 71 in handler_thread
File "threading.py", line 982 in run
File "threading.py", line 1045 in _bootstrap_inner
File "threading.py", line 1002 in _bootstrap

Thread 0x00007e14 (most recent call first):
File "threading.py", line 327 in wait
File "waitress\task.py", line 71 in handler_thread
File "threading.py", line 982 in run
File "threading.py", line 1045 in _bootstrap_inner
File "threading.py", line 1002 in _bootstrap

Thread 0x00003618 (most recent call first):
File "threading.py", line 327 in wait
File "waitress\task.py", line 71 in handler_thread
File "threading.py", line 982 in run
File "threading.py", line 1045 in _bootstrap_inner
File "threading.py", line 1002 in _bootstrap

Thread 0x000076a4 (most recent call first):
File "asyncio\windows_events.py", line 825 in _poll
File "asyncio\windows_events.py", line 444 in select
File "asyncio\base_events.py", line 1898 in _run_once
File "asyncio\base_events.py", line 608 in run_forever
File "asyncio\windows_events.py", line 321 in run_forever
File "openlp\core\api\websockets.py", line 100 in start

Thread 0x00006064 (most recent call first):
File "waitress\wasyncore.py", line 167 in poll
File "waitress\wasyncore.py", line 240 in loop
File "waitress\server.py", line 325 in run
File "openlp\core\api\http\server.py", line 55 in start

Current thread 0x00002cb4 (most recent call first):
File "openlp\core\widgets\views.py", line 108 in resizeEvent
File "openlp\core\app.py", line 84 in exec
File "openlp\core\app.py", line 157 in run
File "openlp\core\app.py", line 616 in main
File "openlp__main.py", line 75 in start
File "openlp__main.py", line 79 in <module>

T4sythe

I was having the same issue. It eventually seemed to stop but still happens occasionally. I wonder if its possibly a RAM issue, we're using a laptop with i5-10300H CPU @ 2.50GHz but only 8gb of RAM. When nothing else is running there doesn't seem to be an issue, when we've got other programmes up like zoom, powerpoint etc, then it struggles and crashes.
Not the most in depth investigation but seems to work for us...

witterholt

T4sythe that would also explain why I can't reproduce it since I have 32GB of RAM.

Timon

Hi @witterholt ,
as I wrote in IRC about a month ago, I was able to reproduce the bug, but it's hard to diagnose. I stopped investigating the cause after hearing there probably wouldn’t be a 3.1.8 release.

Here’s what I can say:

The master branch doesn't have this problem.
I don't think it's RAM-related, because I gave my VM 31GB and it still crashed.
The problem is caused by the Live View.
The problem occurs when the width of OpenLP is reduced — the height doesn't seem to matter. When the width gets reduced far enough that the "Desktop," "Show," and "Blank" buttons collapse into a combo button, that button becomes grayed out and OpenLP becomes unresponsive.
I think that combo button is the cause, or at least a good starting point for finding the issue.

If there will be a 3.1.8 release, I can take a closer look.
@witterholt do you know where that combo button is handled?