LMMS crash when open one of my project

[hashhakaj]

Hello Everyone
I did share this project one year ago and put note it will crash your LMMS 100% when it begins play from claps beat bars section at the end of claps bar, colored in red, if you do extend it.
I've done this with different windows hardware and even I've test it with Mac. all have the same situation.
this experiment is done with LMMS 1.1.3
However, I've test the project in latest version of LMMS 1.2. and it crashed at claps beat faster than in LMMS 1.1.3 .

So, I hope that problem be fixed.
project link
https://lmms.io/lsp/?action=show&file=7616

[tresf]

Confirmed. Thanks for the bug report.

[Umcaruje]

Looks like LMMS is running out of buffers. Backtrace:

BufferManager: out of buffers
BufferManager: out of buffers

Thread 8 "QThread" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffa7074700 (LWP 18198)]
0x00007ffff4244428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0  0x00007ffff4244428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
        resultvar = 0
        pid = 18183
        selftid = 18198
#1  0x00007ffff424602a in __GI_abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x7fff94026010, sa_sigaction = 0x7fff94026010}, sa_mask = {__val = {140735995655936, 140735995656368, 
              140737330365679, 2802268544, 140735676571690, 124560769757, 9644727278355117056, 0, 4294967041, 140737333684128, 10, 140737333684152, 140737293141872, 
              140735995660032, 9644727278355117056, 140735995656480}}, sa_flags = 0, sa_restorer = 0x3}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007ffff67fcf15 in qt_message_output(QtMsgType, char const*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
No symbol table info available.
#3  0x00007ffff67fd371 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
No symbol table info available.
#4  0x00007ffff67fdc91 in qFatal(char const*, ...) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
No symbol table info available.
#5  0x0000000000506bb7 in BufferManager::acquire () at ../src/core/BufferManager.cpp:63
        i = 0
        b = 0xd01ba0
#6  0x000000000058745f in AudioPort::doProcessing() ()
No symbol table info available.
#7  0x00000000005311d6 in ThreadableJob::process (this=0x7fffeaaa3b30) at ../include/ThreadableJob.h:74
No locals.
#8  0x0000000000549bfa in MixerWorkerThread::JobQueue::run() ()
No symbol table info available.
#9  0x0000000000549e43 in MixerWorkerThread::startAndWaitForJobs() ()
No symbol table info available.
#10 0x0000000000544650 in Mixer::renderNextBuffer() ()
No symbol table info available.
#11 0x00000000005460cb in Mixer::fifoWriter::run() ()
No symbol table info available.
#12 0x00007ffff6807e3c in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
No symbol table info available.
#13 0x00007ffff7bc16ba in start_thread (arg=0x7fffa7074700) at pthread_create.c:333
        __res = <optimized out>
        pd = 0x7fffa7074700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735995660032, -2473051717161342296, 1, 140737488344831, 140735995660736, 17178824, 2473244335792827048, 
                2473069832041900712}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#14 0x00007ffff431582d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
---Type <return> to continue, or q <return> to quit---
No locals.

@zonkmachine could this be related to #3169?

[zonkmachine]

@zonkmachine could this be related to #3169?

Yes but I thought that #3169 had been more or less static since around 1.1.0 and here's a change between 1.1.3 and 1.2.0-RC2 . I'll be back to coding in a week and will have a look. A quick thing to test is if this is from before the recent Sample Track updates.

[michaelgregorius]

I have found the problem with the project file and this issue:

1. Open the project file in LMMS.
2. Open the Beat+Bassline Editor.
3. If it's not already selected select "4 claps" from the combo box.
4. Open the Audio File Processor for "clap04.ogg" (third one from the bottom of the list).
5. Go to the ENV/LFO section.

You will find that the release of the AHDSR is set to the maximum value of 2.0. This means that if you trigger many samples like it's done in the song many "notes" with long release times are triggered which will play for so long that all the buffers are used up.

This means that you can also trigger the crash in a fresh project as follows:

1. Add an Audio File Processor to the default project.
2. Load a sample into the AFP, e.g. clap04.ogg from the drums folder.
3. Set the release to 2.0.
4. Click with the mouse on the keyboard of the AFP, keep the button pressed and sweep quickly over the keyboard.

@hashhakaj You can likely solve the crashes in your song by dialing back the release values of the Audio File Processors that you use to play the samples in your song.

However, this is only a solution for that one project and in principle it should never be possible to crash the application by just using some "unfortunate" settings.

[hashhakaj]

@michaelgregorius Thank you for the solution. I reduced the "release" value at '1' and now It works fine without crash even with Beethoven hardcore style.
So, the AFP still one of the most careful instrument to use to avoid program crash. :)

[zonkmachine]

However, this is only a solution for that one project and in principle it should never be possible to crash the application by just using some "unfortunate" settings.

The problem with long envelopes was introduced here: #411

In this specific case I can make the project survive by simply increasing the number of available buffers to 1024. I've seen no side effects from increasing this and I'm on a weaker machine than most of us. This way you are more likely to see your machine eat up the CPU cycles and go looking for the trouble instead of getting a crash.
The second thing that could be done is implementing a switch to multiply the envelope time and the help text would inform of the possible side effects of long envelopes and multiple notes. This way you also get a better dynamic range of the shorter envelopes, both in knob action and graphic representation, which are more common.
Also, when you switch the arpeggiator on the default speed is a bit on the high side, so if you have a note with a long envelope that may cause high CPU action like this. I think it should be dialled down a bit to maybe 1/8th notes at 140 bpm.

[zonkmachine]

I can make the project survive by simply increasing the number of available buffers to 1024.

As it turns out, not by a very big margin. We could just try and raise the available buffers to something bigger, like 4096?

Or you could implement extensible buffers, started here:
https://github.com/LMMS/lmms/blob/master/src/core/BufferManager.cpp#L115:L131

I think we should go with no.1 . Increase available buffers to 4096. Simple and fast.

[Umcaruje]

I think we should go with no.1 . Increase available buffers to 4096. Simple and fast.

Will this affect latency and/or performance in any way?

[zonkmachine]

I haven't seen anything and I'm running 4096 max buffers now. All that will happen is that the usual limit's will kick in place if you actually go ahead and try to use all those buffers. The power of your CPU will basically be your limit instead of an absolute value.

[zonkmachine]

As s_availableIndex grows this is the only place I've found where performance will may take a hit: https://github.com/LMMS/lmms/blob/master/src/core/BufferManager.cpp#L66
int i = s_availableIndex.fetchAndAddOrdered( -1 );

[zonkmachine]

I got tired of reading Qt documentation so I just stuffed some big numbers in there and hoped things would crash.

Running "Krem Kaakkuja" which is slightly more than my machine can run with lmms-1.2.0
const int BM_INITIAL_BUFFERS = sizeof(int); // crash on launching lmms
Ironically crashing with the message 'out of buffers', which should be pretty much all it has...
const int BM_INITIAL_BUFFERS = 65536; // Noticeably harder.
const int BM_INITIAL_BUFFERS = 16384; // Slightly more strained than 512...

I'm curious as to what Valgrind has to say about this.

[zonkmachine]

Edit: post updated

I compared the behaviour of a project on 1.1.3 vs. 1.2.0 with envelope on/off. I think this indicates that the envelope maybe is still running after the sample has finished playing on 1.2.0-rc2 .
Here is the test file.
shortsample.mmp.zip

Results

Version	Action	cpu %
1.1.3	idle	4.5
	no envelope	9
	envelope	11
	envelope + loop	100
1.2.0-rc2.48	idle	6.5
	no envelope	16
	envelope	124
	envelope + loop	maxed out

Envelope means volume envelope amount turned all the way up/down

[michaelgregorius]

I think this issue shows that there are two problems:

• Other instruments, e.g. VSTs, do not allow an arbitrary number of voices being played and use voice stealing strategies in case the maximum of voices is reached and another voice is intended to be played. If it is LMMS' intention to not impose such limitations on the user then it should be implemented in a way that does not have some hidden limitation, e.g. that are dictated by the technical property of available memory buffers. Providing only a limited number of voices also has the big advantage that they can be allocated upfront so that no memory has to be allocated in the audio thread.
• Most samplers provide an ADSR that's interpreted in relation to the sample and its maximum length. The problem with the Audio File Processor is that it uses an envelope that's independent of the sample that's loaded. Here is an example of how the REAPER sampler works:
  https://youtu.be/1pdzzLkEF_U?t=108
  Notice that the envelope cannot be longer than the sample.

[tresf]

The problem with the Audio File Processor is that it uses an envelope that's independent of the sample that's loaded.

Would love to see this fixed (Per #2255 / @LocoMatt)