#1781 Reproducible Rosegarden crash when opening Notation Editor

[musewhirl]

[29193b]: On hitting the Enter key, Rosegarden disappeared from the screen. The only other evidence that something was amiss, is that the logs end with the following, which hints that the NotationEditor was involved.

[SequencerThread] run(): Sequencer status changed from  1  to  0
[NotationTool] NotationTool::findActionInParentView: Can't find ActionFileClient in parent widget hierarchy
[NotationTool] NotationTool::invokeInParentView: No action " "no_accidental" " found in parent view

In addition, on restarting RG it performs a recovery, as shown in the logs for that startup, and offers to recover from an auto saved file. But it only does this if the file was actually open long enough for an auto-save to occur.

I whittled down a rather large session until the path tracked to a single segment which was in the group of segments involved. There is nothing special about the segment which I believe was created with the MatrixEditor. Although it was linked, unlinking it did not change the outcome. The MatrixEditor works just fine, so I even removed all of the notes from the segment, and RG still crashed. On studying the segment element in the rg file, I can see that some rests are still around, but I don't think I can remove those using the MatrixEditor. I created a copy of the troublesome segment (shown below), which can be incorporated into any rg file, preferably a new one.

Steps to reproduce:

1. Create a new RG session
2. Place an empty 2 measure segment on track 1 at the start of the composition
3. By default, the segment label is "Acoustic Grand Piano"
4. Save and close the session.
5. Open the rg file, and there should only be one segment element, probably with track=0, since RG starts at zero under the covers
6. Replace the segment element with that below, matching the track and label of the existing one
7. Open the session
8. Select the segment and press Enter
9. RG windows disappear from screen!

<segment track="0" start="0" label="Acoustic Grand Piano" colourindex="23" snapgridsize="240" endmarker="7680">
    <event type="clefchange" subordering="-250" absoluteTime="0"><property name="groupid" int="1"/><property name="grouptype" string="tupled"/><property name="tupletbase" int="240"/><property name="tupledcount" int="2"/><property name="untupledcount" int="3"/><property name="clef" string="treble"/><property name="octaveoffset" int="0"/></event>
    <event type="keychange" subordering="-200" absoluteTime="0"><property name="groupid" int="1"/><property name="grouptype" string="tupled"/><property name="tupletbase" int="240"/><property name="tupledcount" int="2"/><property name="untupledcount" int="3"/><property name="key" string="A minor"/></event>
    <event type="keychange" subordering="-200" absoluteTime="0"><property name="key" string="C major"/></event>
    <event type="keychange" subordering="-200" absoluteTime="0"><property name="groupid" int="1"/><property name="grouptype" string="tupled"/><property name="tupletbase" int="240"/><property name="tupledcount" int="2"/><property name="untupledcount" int="3"/><property name="key" string="A minor"/></event>
    <event type="keychange" subordering="-200" absoluteTime="0"><property name="key" string="C major"/></event>
    <event type="keychange" subordering="-200" absoluteTime="0"><property name="groupid" int="1"/><property name="grouptype" string="tupled"/><property name="tupletbase" int="240"/><property name="tupledcount" int="2"/><property name="untupledcount" int="3"/><property name="key" string="A minor"/></event>
    <event type="keychange" subordering="-200" absoluteTime="0"><property name="key" string="C major"/></event>
    <event type="rest" duration="3840" subordering="10" absoluteTime="0"></event>
    <event type="clefchange" subordering="-250"><property name="clef" string="treble"/><property name="octaveoffset" int="0"/></event>
    <event type="keychange" subordering="-200"><property name="key" string="C major"/></event>
    <event type="rest" duration="3840" subordering="10"></event>
    <event type="clefchange" subordering="-250"><property name="groupid" int="1"/><property name="grouptype" string="tupled"/><property name="tupletbase" int="240"/><property name="tupledcount" int="2"/><property name="untupledcount" int="3"/><property name="clef" string="treble"/><property name="octaveoffset" int="0"/></event>
    <event type="rest" duration="3840" subordering="10"></event>
  <matrix velocity="100">
    <hzoom factor="3.7975" />
    <vzoom factor="1" />
  </matrix>
  <notation>
  </notation>
</segment>

[musewhirl]

After the last post, I remembered that the original segment had no rests, so the rests which appear in the segment element must have been added by RG after I deleted the notes. So, they probably aren't involved either.

[Philip Leishman]

Yes - there is a check missing in NotationGroup::applyTuplingLine
This bug can be reproduced easily:

1. Create a 1 bar segment at composition start.
2. Open it in the notation editor
3. Press Ctrl-A (select all) and Ctrl-R (make triplet).
4. Crash.
   I put in the check - see merge request.

[Ted Felix]

Philip's fix pushed as [7abf6d]. Please test latest git.

[musewhirl]

I can now open the segments in the original session without a crash. As per the bug description, it's all fixed now and the bug can be closed.

I didn't actually try to create or even have any tuplets in the original segment when it crashed, and with all notes removed I assumed it may have been some leftover notation markers. No way to tell visually in the window, because it was impossible to open the NotationEditor.

When I first looked at the logs, I thought RG left no clues whatsoever...not even a last gasp "I'm, dead!". Then I saw and guessed it might be the NotationEditor. Therefore, I was going to mention the following. Isn't there a way to create a main error handler (trap) so that no matter how RG dies, it attempts to write something more meaningful to the log? I know the kernel can be merciless in some cases and prevent even that, but I don't think that was the case here. Depending on how the code is written, the undo list could still be available from the trap, and it might contain some or all of the steps that occurred just before the crash, except perhaps the last one...and maybe even that if commands are recorded just before carrying them out. It might make determining what happened easier when the window is just gone, and you can't even remember exactly what you were doing. Just a passing thought.

[Ted Felix]

Isn't there a way to create a main error handler (trap) so that no matter how RG dies, it attempts to write something more meaningful to the log?

Probably. But running in the debugger or with ASAN gives us a back trace that immediately finds the problem. No extra code or logging required.

[musewhirl]

That might be true, but I was actually referring to when the error first occurred where I had no idea what had happened. Here is the sequence:

• The screen disappeared and I had no actual idea why or what I did, since I thoughts were on the musical, not mechanical aspects of RG.
• Fortunately, and I emphasize fortunately, it happened twice an hour or so later, and I was sensitive to something being amiss by then
• This time I recall I was about to play the composition after a change, so it must have been the Enter key. But I'd used that key many times during the hour
• Then I realized, that instead of hitting the keypad Enter key, I had inadvertently hit the other Enter key which is defaulted to opening the NotationEditor...which of course never opened, because RG was long dead.
• And this error affected only one segment out of all those in the composition. It just happened to be selected because when a track is selected RG selects all segments on that track.
• In fact, that segment has been in that session for weeks, if not months and never coincidentally triggered the crash, so I initially blamed the new master.

With JACK timing and xruns as finicky as they are, there is no way I can work continuously in a debugger for all sessions. And since I originally had no idea what happened, I almost let the whole thing slide, and would not have reported it since just stating "RG disappeared" as the title of a bug and steps to reproduce "Use RG" would not have helped one bit :-)

Just the reference to the NotationEditor gave the clue, and if that had not been there, the bug would remain until perhaps someone used Philip's (@lman) method.

An overall catch block with access to a few preceding user actions, especially the culprit action before RG disappeared, would not only alert the user to the action which caused the bug, but would also allow the user to more easily reproduce the error. That is where the debugger comes in handy to provide more information to developers, and the user actions are close to the steps to reproduce. The catch block preceding user actions would only appear in the logs during a crash (if the kernel allowed it), assuming that RG can distinguish between a normal exit and an outright crash within the catch block.

Anyway, as I stated earlier, it was just a thought. In my case, I very rarely see crashes in RG.