Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MusE crash when drawing/moving a part #887

Closed
StaffanMelin opened this issue Oct 30, 2020 · 30 comments
Closed

MusE crash when drawing/moving a part #887

StaffanMelin opened this issue Oct 30, 2020 · 30 comments
Labels
bug midi remind Stale

Comments

@StaffanMelin
Copy link
Contributor

StaffanMelin commented Oct 30, 2020 •
edited
Loading

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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 StaffanMelin changed the title MusE crash when drawing a part MusE crash when drawing/moving a part Oct 30, 2020
@StaffanMelin
Copy link
Contributor Author

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

@StaffanMelin
Copy link
Contributor Author

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
Copy link
Contributor Author

StaffanMelin commented Oct 30, 2020 •
edited
Loading

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
Copy link
Member

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

@spamatica
Copy link
Member

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

@spamatica
Copy link
Member

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

@spamatica
Copy link
Member

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 <path_to_the_binary>/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
Copy link
Contributor Author

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
Copy link
Contributor Author

StaffanMelin commented Oct 31, 2020 •
edited
Loading

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
Copy link
Contributor Author

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
Copy link
Member

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

@terminator356
Copy link
Member

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
Copy link
Contributor Author

StaffanMelin commented Nov 1, 2020 •
edited
Loading

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
Copy link
Member

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
Copy link
Contributor Author

StaffanMelin commented Nov 1, 2020 •
edited
Loading

No hurry, the song is intact now! :)

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

@kybos
Copy link
Contributor

kybos commented Jan 13, 2021

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

@terminator356
Copy link
Member

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
Copy link
Contributor

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

@terminator356
Copy link
Member

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
Copy link
Contributor

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

@terminator356
Copy link
Member

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
Copy link
Contributor

donarturo11 commented Sep 11, 2022 •
edited
Loading

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
Copy link
Member

terminator356 commented Sep 11, 2022 •
edited
Loading

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
Copy link
Contributor

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
Copy link
Contributor

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.

@github-actions GitHub Actions
Copy link

github-actions bot commented Sep 7, 2024

This issue is stale because it has been inactive for two years. Remove Stale label or write a comment, otherwise it will be closed in 30 days.

@github-actions github-actions bot added the Stale label Sep 7, 2024
@github-actions GitHub Actions
Copy link

Issue has been closed automatically after two years of inactivity. Feel free to reopen if the issue is still relevant for current MusE version.

@terminator356 terminator356 reopened this Oct 13, 2024
@github-actions GitHub Actions
Copy link

Issue has been closed automatically after two years of inactivity. Feel free to reopen if the issue is still relevant for current MusE version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug midi remind Stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@spamatica @terminator356 @donarturo11 @kybos @StaffanMelin