Frequent segfault that happens without doign anything in LMMS except playing the song

[M4rotte]

Hi,

Sorry for another raw backtrace but I have the following happening randomly way to much:

Thread 30 "lmms::AudioEngi" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff82ffd6c0 (LWP 7869)]
0x000055555586bd28 in lmms::NotePlayHandle::updateFrequency (this=0x20) at /usr/local/src/lmms/src/core/NotePlayHandle.cpp:522
522     int masterPitch = m_instrumentTrack->m_useMasterPitchModel.value() ? Engine::getSong()->masterPitch() : 0;
(gdb) bt full
#0  0x000055555586bd28 in lmms::NotePlayHandle::updateFrequency() (this=0x20) at /usr/local/src/lmms/src/core/NotePlayHandle.cpp:522
        masterPitch = 32767
        baseNote = -2097165672
        detune = 4.59163468e-41
        instrumentPitch = -3.75851476e-37
#1  0x000055555586bffa in lmms::NotePlayHandle::updateFrequency() (this=0x7ffff2a50a48) at /usr/local/src/lmms/src/core/NotePlayHandle.cpp:553
        it = 0x20
        __for_range = @0x7ffff2a50b08: {<QListSpecialMethods<lmms::NotePlayHandle*>> = {<No data fields>}, {p = {static shared_null = {ref = {atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x7fff440519c0}, d = 0x7fff440519c0}}
        __for_begin = {i = 0x7fff6c005960}
        __for_end = {i = 0x7fff440519d0}
        masterPitch = 0
        baseNote = 57
        detune = 0
        instrumentPitch = 74
#2  0x000055555586bffa in lmms::NotePlayHandle::updateFrequency() (this=0x7ffff2a4ff58) at /usr/local/src/lmms/src/core/NotePlayHandle.cpp:553
        it = 0x7ffff2a50a48
        __for_range = @0x7ffff2a50018: {<QListSpecialMethods<lmms::NotePlayHandle*>> = {<No data fields>}, {p = {static shared_null = {ref = {atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x7fff441199b0}, d = 0x7fff441199b0}}
        __for_begin = {i = 0x7fff4405e4d0}
        __for_end = {i = 0x7fff4405e4d8}
        masterPitch = 0
        baseNote = 57
        detune = 0
        instrumentPitch = 74
#3  0x000055555586bffa in lmms::NotePlayHandle::updateFrequency() (this=0x7ffff2a511f0) at /usr/local/src/lmms/src/core/NotePlayHandle.cpp:553
        it = 0x7ffff2a4ff58
        __for_range = @0x7ffff2a512b0: {<QListSpecialMethods<lmms::NotePlayHandle*>> = {<No data fields>}, {p = {static shared_null = {ref = {atomic = {_q_value = std::atomic<int> = { -1 }}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x7fff440b6340}, d = 0x7fff440b6340}}
        __for_begin = {i = 0x7fff440b6350}
        __for_end = {i = 0x7fff440b6358}
        masterPitch = 0
        baseNote = 57
        detune = 0
        instrumentPitch = 74
#4  0x000055555586af5d in lmms::NotePlayHandle::play(std::array<float, 2ul>*) (this=0x7ffff2a511f0, _working_buffer=0x0) at /usr/local/src/lmms/src/core/NotePlayHandle.cpp:239
        framesThisPeriod = 32767
#5  0x0000555555879143 in lmms::PlayHandle::doProcessing() (this=0x7ffff2a511f0) at /usr/local/src/lmms/src/core/PlayHandle.cpp:63
#6  0x00005555557eb962 in lmms::ThreadableJob::process() (this=0x7ffff2a511f0) at /usr/local/src/lmms/include/ThreadableJob.h:77
        expected = lmms::ThreadableJob::ProcessingState::Queued
#7  0x000055555584bfa9 in lmms::InstrumentPlayHandle::play(std::array<float, 2ul>*) (this=0x555568d9c7a0, working_buffer=0x7ffff2a82c80)
    at /usr/local/src/lmms/src/core/InstrumentPlayHandle.cpp:61
        notePlayHandle = 0x7ffff2a511f0
        constNotePlayHandle = 0x7ffff2a511f0
        __for_range = @0x7fff82ffccc8: {<QListSpecialMethods<lmms::NotePlayHandle const*>> = {<No data fields>}, {p = {d = 0x7fff44091aa0}, d = 0x7fff44091aa0}}
        __for_begin = {i = 0x7fff44091ab0}
        __for_end = {i = 0x7fff44091ac0}
        instrumentTrack = 0x7fff00eb0080
        nphv = {<QListSpecialMethods<lmms::NotePlayHandle const*>> = {<No data fields>}, {p = {d = 0x7fff44091aa0}, d = 0x7fff44091aa0}}
--Type <RET> for more, q to quit, c to continue without paging--
        nphsLeft = true
        frames = 0
#8  0x0000555555879125 in lmms::PlayHandle::doProcessing() (this=0x555568d9c7a0) at /usr/local/src/lmms/src/core/PlayHandle.cpp:59
#9  0x00005555557eb962 in lmms::ThreadableJob::process() (this=0x555568d9c7a0) at /usr/local/src/lmms/include/ThreadableJob.h:77
        expected = lmms::ThreadableJob::ProcessingState::Queued
#10 0x00005555557eb316 in lmms::AudioEngineWorkerThread::JobQueue::run() (this=0x555555c0e380 <lmms::AudioEngineWorkerThread::globalJobQueue>)
    at /usr/local/src/lmms/src/core/AudioEngineWorkerThread.cpp:88
        job = 0x555568d9c7a0
        i = 2
        processedJob = false
#11 0x00005555557eb651 in lmms::AudioEngineWorkerThread::run() (this=0x5555569865f0) at /usr/local/src/lmms/src/core/AudioEngineWorkerThread.cpp:178
        mmThreadGuard = {<No data fields>}
        m = {<QBasicMutex> = {d_ptr = {_q_value = std::atomic<QMutexData *> = { 0x1 }}}, <No data fields>}
#12 0x00007ffff64cbd43 in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007ffff62a8044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735391192768, 7883113816014119873, -288, 0, 140737488343984, 140735382802432, -7883138004678679615, -7883095489330224191}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#14 0x00007ffff632861c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

LMMS 1.3.0-alpha.1.483+g67ce16777 (Debian Bookworm)

[michaelgregorius]

Based on the stack trace it seems that there is a NotePlayHandle (line 3) which has other NotePlayHandles as sub notes. These in turn have sub notes (line 2) which in turn also have sub notes (line 1). One of these sub notes believes to also have sub notes but they point to bad memory (line 0) as indicated by (this=0x20). The other this pointers look okay.

So, it's recursive sub notes all the way down. :wink:

[michaelgregorius]

This also looks like a more extreme version of #7011 in the sense that is has deeper levels of sub notes.

[michaelgregorius]

Hi @M4rotte! Have you been using automated chord stacking like described in #7010 in these cases as well? I am asking because this comment in NotePlayHandle.h states: // used for chords and arpeggios

I wonder how these deep recursion levels can be reached in the first place. To me it seems that they should never happen because they might be the equivalent of creating a chord by stacking notes onto a note and then stacking notes on the resulting notes (and perhaps even deeper).

[M4rotte]

Hi, @michaelgregorius Yes I have. Automated using a LFO, not an automation curve. Sorry I can’t give more details. I’m not sure but I think it may be related to a particular plugin: the SF2 player. I’ll give a quick try at making a minimal project which raises the error, this one or #7012, so I could post it there.

[zonkmachine]

@M4rotte Do you have a project for this? I'm failing to replicate this unfortunately. I use note stacking controlled by an LFO with an arpeggiator on top running an sf2. No problem, just avant-garde jazz.

[M4rotte]

Hi,

I had the segfault once while making the following project (ie: an ad-hoc project made on purpose to spot the bug). It happened when I linked another LFO to an arpeggio setting. Sadly, I hadn’t run LMMS in gdb then.

I re-run the project using gdb, then added a few more top-avant-garde items ;) but it did not crash again.

I’ll try to play it longer as soon as I have more time, in the hope it segfaults, so I can provide a back-trace.

test-automation-chord.mmpz.gz

[M4rotte]

Well, I tried hard, really hard, to reproduce that damned segfault, but the linked project is playing for hours now, and it just doesn’t crash. So maybe this quite useless issue should be close after all. I let you guys decide, I’d be OK as far as I’m concerned.

This project masterpiece only has one SF2 (The GM soundfont from the fluid-soundfont-gm Debian package), but twelve LFOs using randomized wave, one of those LFO controls one of another LFO’s parameter. Four plugins: CALF reverb, LMMS Compressor, LMMS Equalizer, and the LMMS Spectrogram.

I’m evenly sad I didn’t manage to make it crash, as happy I had a lot of fun trying to! ^^

LMMS 1.3.0-alpha.1.607+g32fe3e50e
(Linux x86_64, Qt 5.15.8, GCC 12.2.0)

NoisyUtterElusiveSegmentationFault.mmpz.gz

[zonkmachine]

I’m evenly sad I didn’t manage to make it crash, as happy I had a lot of fun trying to! ^^

On behalf of the LMMS Developers: We sincerely apologize.

I'll leave it open for a bit longer as I want to test it some more.

[M4rotte]

Hi,

It finally crashed, but I think I have another problem sadly.

I used the project above, few modifications but nothing drastic, just changed a few LFO parameters, notably: the phase offset of all of them. Also, I was playing it with all the LFO displayed, as the Compressor and Spectrograph too. The song editor and mixer where displayed too, as the SF Player (I join a screenshot).

I let it run while I was doing some groceries, so it may have crashed only about half an hour after start of play, I don’t know.

The problem is that I do not have a backtrace, and I don’t know why, but I think I’m doing something wrong:

Thread 33 "lmms::AudioEngi" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff7dffb6c0 (LWP 48490)]
0x000055555588f128 in ?? ()
(gdb) bt full
#0  0x000055555588f128 in  ()
#1  0x0000000000000000 in  ()
(gdb)

I don’t know if my gdb installation is buggy (GNU gdb (Debian 13.1-3) 13.1)

I think I compiled LMMS the right way:

/usr/local-debug/bin/lmms: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=595b9edf5c1788905e626e7a532ff0d5e5a384ec, for GNU/Linux 3.2.0, with debug_info, not stripped)

LMMS 1.3.0-alpha.1.614+g0a93e1777
(Linux x86_64, Qt 5.15.8, GCC 12.2.0)

But I also have those messages which seem to indicate gdb is not happy:

warning: Can't read data for section '.debug_info' in file '/usr/lib/debug/.build-id/7d/53247ac4bfa12f9be2b7436e8e05b5185877db.debug'
warning: Section .debug_aranges in /usr/lib/debug/.build-id/7d/53247ac4bfa12f9be2b7436e8e05b5185877db.debug entry at offset 0 debug_info_offset 0 does not exists, ignoring .debug_aranges.

and also:

Can't recover from underrun, prepare failed: Périphérique ou ressource occupé

(the second is repeated many times).

Any idea what I am doing wrong?

https://i.imgur.com/AnjcN6P.png

Have a nice weekend.