#1794 NotationEditor crashes undoing a raise or lowering of repeated segment notes

[musewhirl]

Steps to reproduce:

1. Launch rosegarden
2. Open NotationEditor on a repeating segment
3. Hit the 'u' key, which creates a note
4. Hit the [DOWN ARROW] key, which lowers that note
5. Use CTRL-Z to undo the lowering of the note
6. RG no longer exists

Mysteriously, it takes two CTRL-Z hits to crash if [UP ARROW] is used instead. And both crashes also occur using the menu option Adjust/Transpose note items. No crash occurs if undo is used without raising or lowering the note.

[Philip Leishman]

I can't reproduce this - maybe something else about the segment/note ?

[Ted Felix]

No crash for me either. However, the notation editor window gets maximized when I Ctrl+Z undo the first time after launching notation on a four bar repeating segment. Strange.

[Philip Leishman]

I don't get the crash or the maiximize !!

[musewhirl]

I knew this was going to be trouble (much like bug #1792). A devious bug. I think it involves a seemly innocent "set up for the crime" first, then when you do something innocuous later, bam!

For the report I had tried to remove what seemed like superfluous, preposterous keystrokes to keep things simple. Now, forget all that. You get the note-down-crash.rg with the bug imprisoned, and which is exactly what I used. The instructions are simple enough this time:

1. Open RG on the note-down-crash.rg file
2. Hit the Enter key once: Should open the NotationEditor because only one track with the repeated segment already selected...hopefully)
3. Hit the End key once: Don't ask...just do it ;-)
4. Hit the Home key once
5. Hit the 'u' key once (creates a note)
6. Hit the Down Arrow key once (lowers the note)
7. CTRL-Z (should undo lowering of note, but won't make it)
8. And tell me RG is gone!!! (hopefully)

That's it...six keys are you should be there. And now you should have a debug trace which will explain exactly what was going on, and reveal the true minimal to cause the crash. Hopefully!

I'm sure you'll let me know either way, especially why the bug report did not work for you guys.

[Philip Leishman]

No - still no crash. Maybe something different in the settings ?
To find out if a setting is causing this: can you rename your Rosegarden.conf file - then start Rosegarden and go through the steps above. I did this and I got no crash. Afterwards you can copy the original Rosegarden.conf back to get your old settings again.

[musewhirl]

Now I'm surprised. I had already taken into account the Rosegarden.conf by not only avoiding my own, but starting RG with basically a fresh install i.e. nothing with rosegarden existed in either ~/.config or ~/.local/share. That gives me a "Welcome to Rosegarden" screen at start up and RG creates its own config directories.

@tedfelix mentioned something about the NotationEditor maximizing. However, like you, that does not happen for me.

Just so you don't feel left out. I have many sessions where the steps do not cause a crash. And yet, there are others where it repeatedly does. I can't find a pattern between the ones which crash and those that don't.

But the attached session was created from one of those that crashes...and for me, that always crashes. But if I remove the repeat on the segment (CTRL-SHIFT-R) just before carrying out the steps, then it never crashes. The circumstances, and the bug, are trapped in there, and that bug can't sneak off anywhere.

Perhaps we are down to gtk vs qt, and the fact that I am using RG with QT_QPA_PLATFORMTHEME=gtk3 on Debian trixie? Or if this is some dangling pointer issue, the resulting behavior could be indeterminate.

Perhaps @tedfelix might see the problem using just the attached rg file. He did see a behavior, albeit different, which you could not see.

As for here, I'm using [94f7ef], which is very recent, but master has moved since. I'll update to that. If that still exhibits this behavior, I'll have to dig up the steps to set up gdb and put this to bed once and for all.

[musewhirl]

Dang!! It still crashes on the latest master [258be1], so it's not that. I guess it's gdb next.

[Philip Leishman]

Ah !!
I have a Debian Trixie virtual machine
running Rosegarden with QT_QPA_PLATFORMTHEME=gtk3
And - I get the crash !!!

[Philip Leishman]

And (maybe) a fix
See codeberg pull request.

[musewhirl]

Excellent! Well, not excellent that you got a crash, but that you at least can now debug it. And I don't have to install gdb now :-)

I should also mention something else really odd. I confirmed bug #1790 as fixed...but it is not fixed for note-down-crash.rg. This one still opens with the Draw tool selected. However, other similar sessions that I randomly picked, opened with the correct tool. Even the other crashing session that note-down-crash.rg was distilled from opens OK...But note-down-crash.rg opens with the wrong tool. Perhaps another clue.

[Philip Leishman]

The logic is:
If the segement contains notes - default to select tool
If the segment contains no notes - default to draw tool
As the segment in note-down-crash.rg contains no notes it is correct that the draw tool is active.