Segfault at end of commandline render

[softrabbit]

This is what 1.0 and master branch occasionally seem to do at the end when rendering from command line. The output file gets created and rendered fine, so it's maybe not that critical.

Starting program: /tmp/lmms/target/bin/lmms -r data/projects/Shorties/Skiessi-222.mmpz -o /tmp/foo.wav
[omitting thread starts and exits and LMMS output]

ASSERT: "asize <= aalloc" in file /usr/include/qt4/QtCore/qvector.h, line 474

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffa1666700 (LWP 20309)]
0x00007ffff45f3425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff45f3425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff45f6b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff684b50b in qt_message_output(QtMsgType, char const*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3  0x00007ffff684b8bf in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007ffff684ba64 in qFatal(char const*, ...) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x0000000000560b58 in QVector<unsigned short>::realloc (this=0x806188, asize=8452048, aalloc=0) at /usr/include/qt4/QtCore/qvector.h:474
#6  0x000000000055f990 in detach_helper (this=0x806188) at /usr/include/qt4/QtCore/qvector.h:337
#7  detach (this=0x806188) at /usr/include/qt4/QtCore/qvector.h:147
#8  detach (this=0x806188) at /tmp/lmms/src/core/Mixer.cpp:556
#9  begin (this=0x806188) at /usr/include/qt4/QtCore/qvector.h:247
#10 Mixer::renderNextBuffer (this=0x82e9b0) at /tmp/lmms/src/core/Mixer.cpp:654
#11 0x000000000055fe14 in Mixer::fifoWriter::run (this=0x7fff98006200) at /tmp/lmms/src/core/Mixer.cpp:1202
#12 0x00007ffff6855fcb in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#13 0x00007ffff7bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#14 0x00007ffff46b0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6

[SadaleNet]

Duplicate #238
EDIT: amended the issue number

[rcorre]

Having a similar issue here, but with different output from gdb:

Core was generated by `lmms -r resources/lmms/ice_insignia1.mmpz -f ogg -o test.ogg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000004dba07 in FxMixer::processChannel(unsigned short, float (*) [2]) ()
(gdb) bt
#0  0x00000000004dba07 in FxMixer::processChannel(unsigned short, float (*) [2]) ()
#1  0x000000000047b57d in MixerWorkerThread::processJobQueue() ()
#2  0x000000000047f233 in MixerWorkerThread::run() ()
#3  0x00007fbd70b0cebf in ?? () from /usr/lib/libQtCore.so.4
#4  0x00007fbd71e6b314 in start_thread () from /usr/lib/libpthread.so.0
#5  0x00007fbd6e90a3ed in clone () from /usr/lib/libc.so.6

As metioned by @softrabbit above, the output file is generated and seems to be intact.
Version:

Linux MultiMedia Studio 1.0.3
(Linux x86_64, Qt 4.8.6, GCC 4.9.0 20140604 (prerelease))

[tobydox]

Does this still happen with stable-1.1 series from Git?

[rcorre]

I checked out stable-1.1, but the version reports 1.0.95 - is this expected?
Either way, that version still segfaults:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000005218e2 in MixerWorkerThread::startAndWaitForJobs() ()
(gdb) bt
#0  0x00000000005218e2 in MixerWorkerThread::startAndWaitForJobs() ()
#1  0x00000000004fda1a in Mixer::renderNextBuffer() ()
#2  0x00000000004fde74 in Mixer::fifoWriter::run() ()
#3  0x00007f60c2e3debf in ?? () from /usr/lib/libQtCore.so.4
#4  0x00007f60c419c314 in start_thread () from /usr/lib/libpthread.so.0
#5  0x00007f60c0a0c3ed in clone () from /usr/lib/libc.so.6

[tresf]

I checked out stable-1.1, but the version reports 1.0.95 - is this expected?

Yes, that's normal. We back-number until we reach a stable. 1.1.0.

[badosu]

Jist confirmed that this still happens on master with: https://github.com/SecondFlight/lmms/raw/master/data/projects/CoolSongs/Greippi%20-%20Krem%20Kaakkuja%20%28Second%20Flight%20Remix%29.mmpz

[badosu]

Lots of different backtraces for the same problem :/. I guess lmms is eager to delete buffers or something while there's still sound being processed...

Just to be clear, the whole song gets written correctly to the output file, so this is an issue that happens when tearing down internal resources for the exit.

Yet another backtrace gist: https://gist.github.com/badosu/ce6c6d64050416c6aae1

[badosu]

Yeah, looking at the source code it looks like this is indeed the case, see how the app is allowed to be deleted before resources are teared down: https://github.com/LMMS/lmms/blob/master/src/core/main.cpp#L533-539 .

This should have a different logic for the CLI here, and not shared with the GUI, see:

QCoreApplication::instance()->connect( r, SIGNAL( finished() ), SLOT( quit() ) );

[Umcaruje]

Can you comfirm that this is still an issue @softrabbit?

[softrabbit]

Different crash today, but segfault anyway.

Starting program: /home/raine/src/lmms/target/bin/lmms -r data/projects/Shorties/Skiessi-222.mmpz -o /tmp/foo.wav
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
VST sync support disabled in your configuration
loading project...
The following errors occured while loading: 

Unknown LADSPA plugin PhaserI requested.
Unknown LADSPA plugin Plate2x2 requested.
Unknown LADSPA plugin PhaserI requested.
Unknown LADSPA plugin Plate2x2 requested.

done
|------------------------------------------------- |     97%   /  [New Thread 0x7fffe5b89700 (LWP 11041)]
[New Thread 0x7fffba54a700 (LWP 11053)]
[New Thread 0x7fffa2cf9700 (LWP 11052)]
[New Thread 0x7fffbadd3700 (LWP 11045)]
[New Thread 0x7fffbb5d4700 (LWP 11042)]
[New Thread 0x7fffe638a700 (LWP 11040)]
[New Thread 0x7fffe6b8b700 (LWP 11039)]
[New Thread 0x7fffe738c700 (LWP 11038)]
[New Thread 0x7fffe7b8d700 (LWP 11037)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe5b89700 (LWP 11041)]
0x0000000000516a20 in Effect::startRunning (this=0x7fffe80d38a0)
    at /home/raine/src/lmms/include/Effect.h:90
90          m_bufferCount = 0;
(gdb) bt
#0  0x0000000000516a20 in Effect::startRunning (this=0x7fffe80d38a0)
    at /home/raine/src/lmms/include/Effect.h:90
#1  0x000000000051664f in EffectChain::startRunning (this=0x99df90)
    at /home/raine/src/lmms/src/core/EffectChain.cpp:246
#2  0x000000000051d626 in FxChannel::doProcessing (this=0x99df80)
    at /home/raine/src/lmms/src/core/FxMixer.cpp:173
#3  0x00000000005283c4 in ThreadableJob::process (this=0x99df80)
    at /home/raine/src/lmms/include/ThreadableJob.h:74
#4  0x0000000000542131 in MixerWorkerThread::JobQueue::run (
    this=0x975040 <MixerWorkerThread::globalJobQueue>)
    at /home/raine/src/lmms/src/core/MixerWorkerThread.cpp:75
#5  0x000000000054244e in MixerWorkerThread::run (this=0x9a3930)
    at /home/raine/src/lmms/src/core/MixerWorkerThread.cpp:164
#6  0x00007ffff771bb0e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007ffff7bc26aa in start_thread (arg=0x7fffe5b89700)
    at pthread_create.c:333
#8  0x00007ffff4b54eed in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) print m_bufferCount
Cannot access memory at address 0x7fffe80d390c
(gdb) 

[zonkmachine]

@softrabbit Can you replicate this on 1.2 ? I believe this could possibly be an instance of #3555 which has been fixed. There were other command line render crashes fixed too in 1.2 .

[PhysSong]

Closing because many CLI rendering bugs have been fixed since the time this bug report is created. Please feel free to reopen this issue if the crash still happens.