search

muse-sequencer / muse

MusE is a digital audio workstation with support for both Audio and MIDI
https://muse-sequencer.github.io/
Other
644 stars 69 forks source link

MusE crash when drawing/moving a part #887

Open StaffanMelin opened 3 years ago

StaffanMelin commented 3 years ago

Trying to bug hunt, as I have experienced some crashes in master (from 2 days ago):

Have worked on a song for one hour, nothing fancy. Last thing I did was drawing a part in the Arranger.

Last lines from terminal:

QItemSelectionModel: Selecting when no model has been set will result in a no-op. QItemSelectionModel: Selecting when no model has been set will result in a no-op. QItemSelectionModel: Selecting when no model has been set will result in a no-op. free(): double free detected in tcache 2 Aborted

Is MusE writing a log somewhere I can attach next time? Always run muse3 -D?

Muse version: MusE 3.1.1, (git: master - 8e3d4326 - 2020-10-28 14:35:14 +0100)

StaffanMelin commented 3 years ago

Running with "muse3 -D".

Letting the song run when editing parts:

unknown kbAccel 0x1000021 EventCanvas::startPlayEvent 75 70 2 0 EventCanvas::startPlayEvent 73 70 2 0 EventCanvas::startPlayEvent 72 70 2 0 Audio::seek already at frame:1852200 startRolling - loopCount=0, _pos=16128 unknown kbAccel 0x1000021 ACTIVE TOPWIN CHANGED to '' ((nil)) bringing 'Arranger' to front instead of closed window ACTIVE TOPWIN CHANGED to 'Arranger' (0x5628ba766af0) MENU SHARING TOPWIN CHANGED to 'Arranger' (0x5628ba766af0) ACTIVE TOPWIN CHANGED to 'Arranger' (0x5628ba766af0) QItemSelectionModel: Selecting when no model has been set will result in a no-op. QItemSelectionModel: Selecting when no model has been set will result in a no-op. QItemSelectionModel: Selecting when no model has been set will result in a no-op. unknown kbAccel 0x1000021 startRolling - loopCount=0, _pos=6144 Audio::stopRolling state PLAY free(): double free detected in tcache 2 Aborted

StaffanMelin commented 3 years ago

Getting crashes everytime I select parts and move them in the Arranger:

unknown kbAccel 0x1000021 unknown kbAccel 0x4000057 unknown kbAccel 0x1000021 ACTIVE TOPWIN CHANGED to '' ((nil)) bringing 'Arranger' to front instead of closed window ACTIVE TOPWIN CHANGED to 'Arranger' (0x555f0ecca8a0) MENU SHARING TOPWIN CHANGED to 'Arranger' (0x555f0ecca8a0) ACTIVE TOPWIN CHANGED to 'Arranger' (0x555f0ecca8a0) Segmentation fault

StaffanMelin commented 3 years ago

Tried my AppImage from 2020-10-17 and it also crashes at these occasions.

StaffanMelin commented 3 years ago

I compiled and tested with the 3.1.1 release and the problem persists. I have no idea why. I know I have updated Debian 10 since then...

StaffanMelin commented 3 years ago

I will try and remove plugins and see if that solves it...

Removed all plugins. Still same behaviour.

Updated Debian 10 Stable.

Tried to old 3.1.1.

Deleted config-folder.

Still crashes when moving parts.

Tried it on another computer with Debian 10.4 (we are now on 10.6). Still crashes. Beginning to think there is something wrong in the .med-file. Attached.

lars_domino_2020_ballad.med.zip

spamatica commented 3 years ago

So, this only happens in this song? Downloading the song now.

spamatica commented 3 years ago

Another thing to try is to temporarily move away the .config/MusE folder, in case something in the configuration is busted

spamatica commented 3 years ago

Tried it now with a fresh build of muse, nothing bad happens :/

spamatica commented 3 years ago

Another way forward is to build MusE with -DCMAKE_BUILD_TYPE=debug. Argument is for cmake. As it seems to be a allocation issue it might not give any accurate infomation, but I'll list the procedure anyway.

With this version of MusE start it with: gdb /muse3 set args -a (to run muse standalone, this reduces other problems) run (start muse) after this muse should startup, it is however common that the debugger will halt a few times, if this happens, simply type 'cont' and press enter to make the debugger proceed.

When MusE is fully started, provoke the nasty problem and see if the debugger catches it. In which case you can type backtrace in the debugger console. Post all the info from when the debugger halted including the back trace.

It is also possible that a debug built MusE does not exhibit the same problem... which is problematic but it is good to know this too.

StaffanMelin commented 3 years ago

Tried it now with a fresh build of muse, nothing bad happens :/

This is strange. I crashes every version I have with MusE, even on different computers (running Debian 10.4 and 10.6 Stable).

I "solved" it by exporting the note data in a MIDI file, created a new MusE song, and imported the MIDI. Now it works. So it must be something in the song file, I guess.

Compiling a debug version of MusE right now, will report back. Thanks for the help and instructions!

StaffanMelin commented 3 years ago

OK, this is the result when running with gdb:

(gdb) cont
Continuing.
[Thread 0x7fffe2f78700 (LWP 7886) exited]
Setting project path to /home/staffan/Documents/projects/music/lars_domino/lars_domino_ballad
[New Thread 0x7fffe2f78700 (LWP 7889)]
[New Thread 0x7fffe2777700 (LWP 7890)]
[New Thread 0x7fffe1f76700 (LWP 7891)]
fluidsynth sampleRate 44100
[New Thread 0x7fffe12ad700 (LWP 7892)]
[New Thread 0x7fffce098700 (LWP 7893)]
[New Thread 0x7fffbffff700 (LWP 7894)]
pad bass S: loading chunk from sysex!
[New Thread 0x7fffbf7fe700 (LWP 7895)]
INFO: Requested timer frequency:1024 actual:1000
[New Thread 0x7fffbeffd700 (LWP 7896)]
strings S: loading chunk from sysex!
projPathPtr /home/staffan/Documents/projects/music/lars_domino/lars_domino_ballad
Number of soundfonts for this instance: 1
SOUNDFONT FILENAME + PATH /home/staffan/Documents/media/audio/sf2/piano/25piano/Full Grand Piano.sf2
--- END PARSE INIT DATA ---
fluidsynth: warning: No preset found on channel 9 [bank=128 prog=0]

Thread 18 "muse3" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffbffff700 (LWP 7894)]
0x00007ffff2ebba92 in std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) cont
Continuing.

[1]+  Stopped                 gdb /home/staffan/Documents/projects/music/programs/muse/muse3/build/muse/muse3

I did it once more, but before I moved the parts I deleted the Fluidsynth synth. I still got the same warning about "fluidsynth: warning: No preset found on channel 9"...

StaffanMelin commented 3 years ago

And here is the backtrace:

(gdb) backtrace
#0  0x00007ffff2ebba92 in std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () at /lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff7d46433 in std::_Rb_tree<unsigned int, std::pair<unsigned int const, MusECore::MidiCtrlVal>, std::_Select1st<std::pair<unsigned int const, MusECore::MidiCtrlVal> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, MusECore::MidiCtrlVal> > >::_M_erase_aux(std::_Rb_tree_const_iterator<std::pair<unsigned int const, MusECore::MidiCtrlVal> >)
    (this=0x555558e32900, __position=Python Exception <class 'gdb.error'> No type named std::_Rb_tree_node<struct std::pair<unsigned int const, MusECore::MidiCtrlVal>>.: 
...)
    at /usr/include/c++/8/bits/stl_tree.h:2491
#2  0x00007ffff7d45698 in std::_Rb_tree<unsigned int, std::pair<unsigned int const, MusECore::MidiCtrlVal>, std::_Select1st<std::pair<unsigned int const, MusECore::MidiCtrlVal> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, MusECore::MidiCtrlVal> > >::erase[abi:cxx11](std::_Rb_tree_iterator<std::pair<unsigned int const, MusECore::MidiCtrlVal> >)
    (this=0x555558e32900, __position=Python Exception <class 'gdb.error'> No type named std::_Rb_tree_node<struct std::pair<unsigned int const, MusECore::MidiCtrlVal>>.: 
...)
    at /usr/include/c++/8/bits/stl_tree.h:1141
#3  0x00007ffff7d44f43 in std::multimap<unsigned int, MusECore::MidiCtrlVal, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, MusECore::MidiCtrlVal> > >::erase[abi:cxx11](std::_Rb_tree_iterator<std::pair<unsigned int const, MusECore::MidiCtrlVal> >)Python Exception <class 'gdb.error'> No type named std::_Rb_tree_node<struct std::pair<unsigned int const, MusECore::MidiCtrlVal>>.: 
 (this=0x555558e32900, __position=...)
    at /usr/include/c++/8/bits/stl_multimap.h:707
#4  0x00007ffff7d799fd in MusECore::PendingOperationItem::executeRTStage()
    (this=0x5555556cb5f0)
--Type <RET> for more, q to quit, c to continue without paging--
    at /home/staffan/Documents/projects/music/programs/muse/muse3/muse/operations.cpp:1303
#5  0x00007ffff7d7ae7e in MusECore::PendingOperationList::executeRTStage()
    (this=0x555555f58e80)
    at /home/staffan/Documents/projects/music/programs/muse/muse3/muse/operations.cpp:1735
#6  0x00007ffff7e33829 in MusECore::Song::executeOperationGroup2(MusECore::Undo&) (this=0x555555f56cf0)
    at /home/staffan/Documents/projects/music/programs/muse/muse3/muse/undo.cpp:1724
#7  0x00007ffff7dd8372 in MusECore::Song::processMsg(MusECore::AudioMsg*)
    (this=0x555555f56cf0, msg=0x7fffffffbaf0)
    at /home/staffan/Documents/projects/music/programs/muse/muse3/muse/song.cpp:2113
#8  0x00007ffff7c8959f in MusECore::Audio::processMsg(MusECore::AudioMsg*)
    (this=0x5555561dc010, msg=0x7fffffffbaf0)
    at /home/staffan/Documents/projects/music/programs/muse/muse3/muse/audio.cpp:1551
#9  0x00007ffff7c866aa in MusECore::Audio::process(unsigned int)
    (this=0x5555561dc010, frames=512)
    at /home/staffan/Documents/projects/music/programs/muse/muse3/muse/audio.cpp:643
#10 0x00007ffff76782be in MusECore::AudioDevice::processTransport(unsigned int)
--Type <RET> for more, q to quit, c to continue without paging--
    (this=0x5555562a48f0, frames=512)
    at /home/staffan/Documents/projects/music/programs/muse/muse3/muse/driver/audiodev.cpp:128
#11 0x00007ffff767a956 in MusECore::dummyLoop(void*) (ptr=0x5555562a48f0)
    at /home/staffan/Documents/projects/music/programs/muse/muse3/muse/driver/dummyaudio.cpp:313
#12 0x00007ffff6cb6fa3 in start_thread (arg=<optimized out>)
    at pthread_create.c:486
#13 0x00007ffff2bad4cf in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) cont
Continuing.

[4]+  Stopped                 gdb /home/staffan/Documents/projects/music/programs/muse/muse3/build/muse/muse3
terminator356 commented 3 years ago

Crash observed! Thanks very much for the test file. Investigating...

terminator356 commented 3 years ago

Found the problem. Working on the solution...

In the meantime, to move forward without errors, please open your project(s) and remove any duplicate midi controller events at the same event time as shown in the snapshot below. There are multiple Sustain events. Remove all except one.

This is a bug (oversight) because duplicate controller events must not be allowed. Duplicate controller events must not be allowed to be entered in the event list, and they must not be allowed in the song files, The underlying code never expects these duplicate controller events, and it crashes as a result!

duplicate_controllers_2

StaffanMelin commented 3 years ago

Thanks for finding the culprit!

Hehe, selected all Sustain events and pressed Delete. Muse crashed! :) But I can select one at a time, that works. And then I can move the parts w/o problems. Great!

As it worked when I exported a MIDI file and imported it, duplicate controllers on the same event time are probably filtered at import time?

terminator356 commented 3 years ago

Observed. Try deleting one at a time, seems to work here. My fixes will remove them from the song for you Hang in there... Much to do...

StaffanMelin commented 3 years ago

No hurry, the song is intact now! :)

Those sustains are from the pedal connected to my Alesis QS8 synth. Wonderful keys!

kybos commented 3 years ago

Is that one fixed? I think I saw some new code from Tim related to this...

terminator356 commented 3 years ago

Er, well, yes. I now prevent anyone from entering duplicate controller events at the same time value in the list editor. But there are still some underlying low-level preventions and checks to be added, I got side-tracked, so a pre-existing song (such as the OP's) with these duplicate controllers might still crash.

Hm, I'd leave this open for now until I can truly say it's been taken care of.

donarturo11 commented 1 year ago

I have a similar problem, when I'm trying to delete track consisting non-conntinuous blocks. I have double free or corruption (fasttop).

terminator356 commented 1 year ago

I forgot about this bug. Although, new projects should never allow it to happen now, so I left it alone. @donarturo11 You may have a different bug. This bug concerned duplicate controller events. See if you can provide more details or steps to reproduce it. Maybe file a new issue for it if necessary. Thanks.

donarturo11 commented 1 year ago

@terminator356 Oh sorry... rush is the bad (while reading too). But I'll try to test this issue.

terminator356 commented 1 year ago

Aaand... the ball comes back here from the Pull Request page ;-)

Thank you very much for the file @donarturo11 Yes, you are indeed having this bug. Here is your song - it is appears virtually the same picture as posted above with song from @StaffanMelin Notice that in the picture I am moving a part which has multiple controller events at the same event time. At this point MusE has crashed.

Screenshot_20220910_174638

Corresponding offending location in your song file, line 13308: <event tick="120772" type="1" a="2" b="118" /> <event tick="120772" type="1" a="2" b="118" />

There are many such offending locations in your song file :-(

So... What caused it? Well, I'm pretty sure you didn't manually enter each one of all these duplicate values, inside the Event List Editor, since I forbid that now, as I said above. You are sure this song file was created in 2022, eh? (That is after I added the fixes mentioned above.) And your MusE version is after the fixes mentioned above? Hm...

It appears that the values may have been part of a line drawing inside the controller lane editor. (The values are part of a series of values representing a straight diagonal line.) So it could be the line drawing code. Maybe I forgot to ensure that it does not allow duplicate values at the same event time. But... there is more than one such line on the graph and it appears that it is possible that Copy and Paste could also have been used to create the lines. (They all seem identical.) So it could be that as well.

Please wait. I'll try to test both of those operations to see if I missed something in there... Thanks.

donarturo11 commented 1 year ago

You are sure this song file was created in 2022, eh?

Yes. Is imported from MIDI file created on MuseScore.

Notice that in the picture I am moving a part which has multiple controller events at the same event time. At this point MusE has crashed.

Program not should be more resistant of similar cases? My last contribution uses method implemented in midictrl.cpp:676. Described implementation is a very good example of error resistant code.

terminator356 commented 1 year ago

Yes. Is imported from MIDI file created on MuseScore.

Wow. That is strange. So the file is basically an untouched import from muse score? After import, were any changes made, especially to the controller graphs?

Thanks. Now I can also check our midi import code.

Would it be possible to share that muse score file with me?

donarturo11 commented 1 year ago

I shared on Dropbox directory. In the meantime I tested some variants to resolve this problem. Maybe file can have some errors, but if program crashes, so probably the code is not enough stable and error resistant. I'm sorry that I'm a little impatient with asking to review but I'm going to fix crashing in undo.

donarturo11 commented 1 year ago

In my humble opinion, ideal program should be too idiots resistant, so the best is choose solution, which file won't cause crash program. I resigned from algorithm checking if item is in list, but I used method from class defined inside this program. While developers won't resign from ifdef condition in methods, better use more complicated method from midictrl.cpp, like in my latest commit.