tags 985129 + unreproducible moreinfo
thanks
(Don’t let this scare you, let’s see whether we can get to the bottom…)
Hi Paul,
> Today *musescore-general-soundfont* was upgraded, and opening a file in
> MuseScore 3, and changing the sound font of a voice/part to *Oboe* MuseScore 3
> crashed with a segmentation fault.
this is unfortunate. Sadly, it’s not quite unexpected; MuseScore is not
fuzzing-resistant and often crashes when loading corrupt scores, for ex‐
ample, and upstream does not seem interested in fixing this systematically,
although this particular crash is.
I’ve tried to reproduce it, running under Valgrind even (an exercise in
slowness), but, while Valgrind is very unhappy with both the X libraries
and MuseScore, showing *many*
Conditional jump or move depends on uninitialised value(s)
messages, only one of them lies in Fluid, and nowhere even near the area
you experienced. (Your full backtrace is extremely helpful.)
Looking at the backtrace…
#0 FluidS::Sample::optimize() (this=this@entry=0x56307713c970) at
./fluid/voice.cpp:1817
val = <optimized out>
s = 0x56307713c970
peak_max = 0
peak_min = 0
peak = <optimized out>
i = 29362
… and the code…
1816 for (i = (int)s->loopstart; i < (int) s->loopend; i ++) {
1817 signed short val = s->data[i];
… this looks like an out-of-bounds access of s->data (perhaps it’s not
29363 elements long). If you have the debug session still (e.g. from a
core dump), can you please run:
(gdb) print *s
This would give us information with which we can look at it in more
depth. There’s a (very small) chance the soundfont has broken values.
> I am unable to reproduce the issue, so I am
> unsure, if it’s related to upgrade at all.
Given this, it could be some, basically, fluke: perhaps the soundfont
was not yet fully loaded/decompressed while you were doing the change?
Umm… I am assuming, but better ask: did you upgrade the soundfont
while MuseScore was running, and, if so, did you not restart it
between upgrading and crashing? (That could explain a crash as well.)
I’ll also ask around upstream whether someone recalls something in
Fluid, but I doubt that will yield much response.
Looking at the diff, two things changed in that area: i was changed
from int to size_t (as is proper, but almost certainly not involved
here), and two checks were added (ugly indentation courtesy upstream):
+ IF_ASSERT_FAILED(s->loopstart >= s->start) {
+ s->loopstart = s->start;
+ }
+
+ if (s->loopend > s->end) {
+ s->loopend = s->end;
+ }
The print command above would show whether this would have made
a difference.
Thanks for reporting,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
