midi import crashes semi-randomly with large files #6160
Comments
|
Testing with latest master, I've imported the midi 4/4 times. The fourth though I did get a freeze only when closing LMMS which wouldn't be related to the midi itself. There are known issues with 1.2.x and MIDI, which is why it will fail to import with 1.2.x. I'd say 99% of problems with MIDI loading were fixed with an update I did for 1.3.0 though. Additionally with the latest master there have been two or three commits fixing a few issues with JACK. |
|
In case there's something causing LMMS to crash, you can use $ gdb lmms
(gdb) runThis will open lmms like normal, import the MIDI and if anything crashes during that it will catch it and you can get a backtrace to where it crashed ( |
I noticed the file provided took a good while to import, does your system kill "unresponsive" processes? That might be recorded in some log. |
|
Tested on 1.3.0-alpha1.130, Arch 5.14, Xorg, during a RAID scrub... Cannot reproduce. Though I discovered that pressing Cancel during import does nothing. |
|
You said it's not a memory problem, meh, I'll just link some stuff I found anyway |
You weren't suppose to find out about that! 😂 Yeah that's something I've known about but I just haven't fixed yet. |
|
When loading the attached midi file in my own MIDI program, I discovered that it does not have a time signature event. |
MIDI defines the default time signature as 4/4, it isn't needed. EDIT: MIDI spec says EDIT2: LMMS doesn't care if the import has a time signature or not, too. It will default to whatever time signature you have set in LMMS. |
|
tested again with 1.3.0 - gdb prints a bit more, but nothing useful to me either. Shortened gdb output: entering bt returns: my system doesn't kill unresponsive processes, otherwise a lot more would crash on my pentium potato :P besides, no log says anything about a process being killed (tried journalctl, /var/log and dmesg) edit: oops forgot to compile debug version, I'll try it again with that in a bit. |
Unless you manually killed the process, your system killed it: |
|
This is turning into a murder mystery. There is no stack trace and all processes have perfect alibis! |
|
So I did a bit more testing (this time with a debug build) - seems the crash only happens with the jack backend selected. That's odd considering any backend goes over pipewire anyway (including alsa) - I tested SDL, alsa, Pulseaudio and dummy, without any crashes. I also tried to get more crash information from the jack version, but either I have no idea how to use gdb or it somehow doesn't work this way either. I tried this: very strange, I do not know what to make of this. add. note: the debug build is from commit g770d2498b now |
|
oh, there's something in journalctl now, I'll see what I can find there |
|
okay so this is what's printed per-crash, in journalctl: I'm not sure how much of that log is relevant, so I just pasted everything which seemed vaguely related (this all happened in 4 seconds, so there might be some other stuff in there) |
|
Okay try this and we'll see if this is something happening in MIDI import itself or afterwards: $ gdb ./lmms
# these will probably prompt about "depend on future import" or whatnot, just say 'yes'
(gdb) break MidiImport.cpp:307
(gdb) break MidiImport.cpp:586
# let's try using the GUI first, then we can try the --import path later
(gdb) run
# import the MIDI like normal, LMMS will freeze when it starts the import, click back in gdb window
(gdb) c
# we just want to know LMMS gets to the start of the main import function, "c" continues running LMMS
# the next breakpoint is the end of the main import function,
# if we crash before it breaks then there's an issue in the import, otherwise we know it's after |
|
the crash is after the first, but before the second breakpoint - I already mentioned this in the original issue report, but some of the midi does import. It crashes (in this case) at about 75%. |
Yeah this is just ensuring it's within that function. Let's add a breakpoint to figure out what track is causing the failure (if it's during the track loading). # you don't need the other breakpoints, only this one now
# add breakpoint at start of track handling loop
(gdb) break MidiImport.cpp:408
# every break, check the trackName and trk variable
# I forget if this is the right way to print the trackName data, this may not print the actual string
(gdb) p trackName.toUtf8().data()
# this will tell us if the trk is not null
(gdb) p trkAfter one of the breaks we hopefully will get the track that's causing the issue and then we can work from there to figure out the issue. |
|
I've only ever used QtCreator for debugging, but what about: |
|
Might work! Not sure anything is thrown though. Doesn't hurt to try. |
|
@Veratil Shortened Output: The full output is here Also I noticed that |
|
@Veratil didn't work - so it doesn't throw anything, which is also very weird. |
I didn't expect anything to be thrown, there are no throws in portsmf (yet). Even though it's a C++ project it's written mostly in C.
Okay so something it happening during the 13th track. Looking at it, it has a lot of notes. It might be a OOM thing. Now that we know it's breaking on track 13, let's debug more during this loop. Do the same thing as before (you don't need to break MidiImport.cpp:420
break MidiImport.cpp:452
break MidiImport.cpp:465
break MidiImport.cpp:472
break MidiImport.cpp:494
break MidiImport.cpp:536Once those breaks are in place, using I'd say alongside this use |
|
It was killed after 536, with no visible change in memory consumption. The output (after the last continue) is as follows: |
|
A segfault is a better error now! Could you get a |
|
nope, it still says |
|
can't reproduce with master anymore, no idea what fixed it, but I'm glad it's gone now. |
Bug Summary
The midi import can just …crash with certain midis. I think the size of the midi imports plays a role, although I haven't yet found any specific file that crashes lmms every time. lmms only prints "killed" to output and leaves no backtrace.
Steps to reproduce
Expected behavior
midi file gets imported, or, if absolutely not possible otherwise, an error message gets displayed importing is stopped
Actual behavior
midi gets imported sometimes, lmms crashes sometimes (usually after a short wait or after some of the midi has been imported)
Affected LMMS versions
At least 1.2.0 and 1.3.0-alpha.1.126+gace502f1a on Arch linux 5.10.59.52 with wayland/sway 1.6.1 and jack/pipewire 0.3.35
Notes
It's not an out-of-memory exception, according to htop (and my combined RAM size of 7.76GiB) and neither is it a problem with wayland nor pipewire since nothing shows up in journalctl - I'm not a C++ dev, so idk how to debug further. I'm absolutely willing to do whatever it takes to get this fixed though, if I'm the only one able to reproduce this.
test midi - fails to import 9/10 times
The text was updated successfully, but these errors were encountered: