#1713 UI locks up when hitting "Record"

[Hugo van Galen]

I'm always running the development version and weirdly enough, today I observed a UI lock-up that I haven't ever seen before.

I had no issues initially, but I am unsure whether this is because I almost always do punch-in recording, and that's where this bug doesn't happen for me.

I'm on Kubuntu 24.04.1 LTS and using QT 5.15.13.

When the bug does not happen
If I hit record during playback, it all works fine.

When the bug does happen
If I hit record while Rosegarden is not playing anything.

What I figured out
I see that, once Record is tapped, execution eventually hits the method RosegardenSequencer::record() where, it uses a QMutexLocker via the macro LOCKED. At the bottom of this record() method, the RosegardenSequencer::play() method is called, that has a LOCKED macro at the start as well. So it kinda makes sense the application "spinlocks" here.

What I could do to work around the problem
At a whim I removed the LOCKED from the play() method and then I do not observe the lock-up.
Likewise, when, just before play() gets called, I insert a m_mutex.unlock(); the bug also goes away. So this is what I have in my own local code right now. I'm still wondering whether there's an underlying cause for this.

More thoughts
Even though it kinda makes sense that it locks up at that point, what I don't understand that I'm only observing this today. If I check the history in version control, it seems the file I edited today hasn't been touched in that area, so that leads me to think I should run into this earlier. I had a copy of an older binary somewhere on my machine (built on 2025-01-09) where I do not observe this issue at all. So that's quite confusing.)

[Philip Leishman]

This was my mistake.
Your analysis is correct. The Mutex is supposed to be recursive allowing for nested "LOCKED" calls.
Unfortunately in my last change I missed some Qt version checks so the mutex was not recursive (for Qt 5.15)
Please merge

[Hugo van Galen]

I am observing what I suspect is a similar lock-up when I try to set a loop range in the ruler while the song position is outside of that range. (This happens regardless of whether the song is playing.)

Edit: Yeah, same type of issue, RosegardenSequencer::setLoop() calls jumpTo() that also attempts a lock, so calling m_mutex.unlock() before jumpTo() is called fixed that issue too.

[Philip Leishman]

Yes - that's the same bug.
Thanks for finding this. By catching this early you save a lot of problems for other users,

[Ted Felix]

Pushed as [e8d16c]. Please test latest git.