Use of uninitialised memory in Ms::TextLineBaseSegment::layout() (textlinebase.cpp:235)
Valgrind reports:
==21024== Conditional jump or move depends on uninitialised value(s)
==21024== at 0xBA6043: Ms::TextLineBaseSegment::layout() (textlinebase.cpp:235)
==21024== by 0xAB846E: Ms::HairpinSegment::layout() (hairpin.cpp:115)
==21024== by 0xAF2AE3: Ms::SLine::layoutSystem(Ms::System) (line.cpp:816)
==21024== by 0xAE0937: Ms::processLines(Ms::System, std::vector >, bool) (layout.cpp:2939)
==21024== by 0xAEBFF4: Ms::Score::collectSystem(Ms::LayoutContext&) (layout.cpp:3378)
==21024== by 0xAEDB36: Ms::LayoutContext::collectPage() (layout.cpp:3586)
==21024== by 0xAEEC19: Ms::LayoutContext::layout() (layout.cpp:3875)
==21024== by 0xAEF564: Ms::Score::doLayoutRange(int, int) (layout.cpp:3861)
==21024== by 0xBDE8D6: Ms::Score::update() (cmd.cpp:222)
==21024== by 0x812C71: Ms::readScore(Ms::MasterScore*, QString, bool) (file.cpp:2330)
==21024== by 0x81334C: Ms::MuseScore::readScore(QString const&) (file.cpp:346)
==21024== by 0x680D63: Ms::convert(QString const&, QJsonArray const&, QString const&) (musescore.cpp:3389)
This is the following line:
232 qreal l = 0.0;
233 if (!_text->empty()) {
234 qreal textlineTextDistance = _spatium * .5;
235 if (((isSingleType() || isBeginType()) && (tl->beginTextPlace() == PlaceText::LEFT)) || ((isMiddleType() || isEndType()) && (tl->continueTextPlace() == PlaceText::LEFT)))
236 l = _text->pos().x() + _text->bbox().width() + textlineTextDistance;
237 qreal h = _text->height();
This happens when batch-converting some MuseScore 2.x-saved scores.
Comments
Pretty sure this is either
tl->beginTextPlace()
ortl->continueTextPlace()
(actually probably both) because thoseisSomethingType()
macros all checkspannerSegmentType()
, and at least one of them was called earlier in the code.I can’t figure out where this needs to be initialised, though.
Unfortunately, valgrind and dr.memory both crash as soon as I start MuseScore on my pc, and memory sanitizer gives tons of false positives (because I did not recompile licxx with -fsanitize=memory) so I can't reproduce.
@mirabilos : do you have the output for such an error when running valgrind with "--track-origins=yes"? In principle it should show where in the code the uninitialised variable was allocated.
In reply to Unfortunately, valgrind and… by ABL
Not yet, but I can provide that soon, testing a new build with your PR 4001 replaced by the combined PR 4278 now.
Does this help?
It’s not finished running, but this is the error I mean.
The code line in question is:
In reply to Does this help? ==30306==… by mirabilos
Ah, forgot: the score is not one I can share publicly, but borrowing it to a fellow developer until the bug is fixed will be fine (or if you have bought Willcocks’s Carols for Choir, I suppose).
It happens during loading the score.
Thank you. Actually, it really helps a lot :-)
From what I see, when a hairpin is initialized, _beginTextPlace and _continueTextPlace are created as part of textLineBase, here:
https://github.com/musescore/MuseScore/blob/428542a52a5862474b8bca59d5b…
_beginTextPlace is then initialized here: https://github.com/musescore/MuseScore/blob/428542a52a5862474b8bca59d5b… to its default value for hairpins: https://github.com/musescore/MuseScore/blob/428542a52a5862474b8bca59d5b…
However, _continueTextPlace is left uninitialized; most of the times it gives me PlaceText::AUTO when querying the hairpin, but once I managed to see it return -120.
I think a solution could be to add
resetProperty(Pid::CONTINUE_TEXT_PLACE);
after line 412and a default
case Pid::CONTINUE_TEXT_PLACE:
after line 624, or, maybe even better, add it as a fallthrough inreturn int(PlaceText::AUTO);
case Pid::BEGIN_TEXT_PLACE
to a defaultPlaceText::LEFT
.See PR:
https://github.com/musescore/MuseScore/pull/4357
The use of left alignment also corrects the horizontal position of continue text [e.g. (cresc.)] for hairpin lines spanning over multiple lines.
Fixed by Werner in 445f907aa
Thanks a lot for tracking down all these (memory corruption, instability, crashes, data corruption, etc.) bugs! I’m trying, but I’m not yet familiar enough with the tools, let alone the codebase, to do them all on my own.
Automatically closed -- issue fixed for 2 weeks with no activity.