#1638 Crash when resizing segment
Crash when resizing segment in main window, but only if Matrix Editor is open with velocity (or other?) ruler shown. Seems to be similar to ancient Bug#655 but stacktrace is different. Because crash requires a very specific set of conditions to trigger I doubt if there's much point in addressing it this late in the 2022.06 release cycle, but am filing this report for future reference. Note also that crash is very consistent across a wide span of code versions, including pre-2022.06 [329ab4] and [52c2f9], 2021.12, and my own repo's pre-merge-request branch with significant changes in src/gui/editors/*.{cpp,h}.
Steps to recreate:
1. New RG document.
2. Create one measure long segment.
3. Open in Matrix Editor (does not crash if no editor, or only Notation Editor is open).
4. Show Velocity Ruler (no crash if not).
5. Set grid to 1/4 notes.
6. Create two 1/4 notes, one each on first and fourth beat of measure (pitch unimportant).
7. Return to main window leaving Matrix Editor open.
8. Resize tool. Resize segment from end by one beat so is 3 beats long.
9. Resize segment from beginning so is 2 beats long.
10. Crash. (Resizing must be done in steps 8 and 9 order as described.)
Stack trace:
(gdb) where 10
#0 0x00007ffff36ac3d6 in __dynamic_cast () at /usr/lib64/libstdc++.so.6
#1 0x00000000009ffac0 in Rosegarden::PropertyControlItem::update() ()
#2 0x00000000007a25bc in Rosegarden::ControlRuler::notationLayoutUpdated(long, long) ()
#3 0x00000000007b0683 in Rosegarden::ControlRulerWidget::slotUpdateRulers(long, long) ()
#4 0x00007ffff57b1d1f in QMetaObject::activate(QObject*, int, int, void**) ()
at /usr/lib64/libQt5Core.so.5
#5 0x00000000004a580b in Rosegarden::Segment::contentsChanged(long, long) ()
#6 0x00000000004d65fa in Rosegarden::BasicCommand::execute() ()
#7 0x0000000000959b9d in Rosegarden::MacroCommand::execute() ()
#8 0x00000000004ebea8 in Rosegarden::CommandHistory::addCommand(Rosegarden::Command*) ()
#9 0x00000000006d8fab in Rosegarden::SegmentResizer::mouseReleaseEvent(QMouseEvent*) ()
(More stack frames follow...)
Code:
void PropertyControlItem::update()
{
if (!m_element) return;
// RulerScale *rulerScale = m_controlRuler->getRulerScale();
double x0,x1;
long val = 0;
MatrixElement *matrixelement = dynamic_cast<MatrixElement*>(m_element);
if (matrixelement) {
...
On crashing, m_elementis not nullptr but is pointing to a non-MatrixElement* memory location, thus crashes trying to find the vtable for the dynamic_cast. This is one of the many areas of the RG codebase I'm not familiar with, so hoping someone with more knowledge can look into it at some point. On casual inspection it's curious that a method named "notationLayoutUpdated" is calling code which casts to a MatrixElement, but that's probably not the problem.
This crash seems related to velocity ruler and not to matrix.
It can be reproduced with a notation editor window as well:
1. New RG document.
2. Create four bars long segment.
3. Open in Notation Editor.
4. Show Velocity Ruler.
5. Create one quarter note on first beat of bar 4.
6. Return to main window leaving Notation Editor open.
7. Resize tool. Resize segment from end by one bar.
8. Crash.
It seems that if a segment is resized (made smaller) Notes after the (new) end of the segment are not erased ! If you resize back to the original size the note is still there.
This seems to be very odd behavior. Surely the note must be deleted ????
Well maybe that is just the way it works!!
However the observers were not being informed about the items disappearing. If I add a
notifyRemovecall for these elements inViewSegment::endMarkerTimeChangedI believe the crash disappears. However on lengthening again the Velocity items do not come back.I can work on this one !
It seems that if a segment is resized (made smaller) Notes after the (new) end of the segment are not erased ! If you resize back to the original size the note is still there.It's how it works.
Similarly entire segments can be hidden if the duration of the composition is reduced then recovered when it is reset to its initial value.
Nevertheless I just discover there is an asymmetry when a segment is resized:
Resizing a segment by its end doesn't remove events.
Resizing a segment by its start removes events.
This is certainly related to the existence of an end marker in each segment while there is no start marker. We are living with it since years and this is not a real problem, but it would be better to have a more symmetrical behaviour.
So I have a fix which tells the ViewSegmentObservers the notes are deleted or created when the segment is resized (although they are not really deleted and created) !
I think the events after the end marker are effectively gone so this should not cause any problems.
See merge request.
Right. I was always a bit unsure what EndTime and EndMarkerTime really mean. Thanks for the explanation Yves. Actually reading the comments for the methods helps too ;)
The asymmetry is maybe a little annoying but, as you say, we are living with it and I wouldn't change that !
Pushed as [30de58]. Please test latest git.
I fixed what appears to be a memory leak:
The ViewElement created by the first call to
makeViewElement()is lost. Fixed version:Let me know if that is wrong. Thanks.
Related
Commit: [30de58]
Last edit: Ted Felix 2022-05-30
Yes, sorry, that was what I intended !!
Thanks for catching that