1.0.92 Crash during chord arpeggio & playback

[musikBear]

win 32xp
http://snag.gy/2J65g.jpg
https://www.sendspace.com/file/qm0nsh
This file crash lmms almost emediately after you set arpeggio ON in the 3oc
I think its related to #985, but wheares 985 happen during 'stressy' mouse-moving of a note, and hence could be caused by either note-moving in piano-roll, or arpeggio-code, this crash is in normal use.
arpeggio is bugged

[diizy]

Cannot reproduce.

[musikBear]

diizy , also on win32?
someone with win32 need to try the file, and report back. It happens evry time on xp
..well, in fact all OS needed to confirm / reject -If all cant, then its a dead-sentence for xp i gues :/

[grejppi]

Happens here too. Ubuntu 14.04, 64-bit. (Qt 4.8.5)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff858a4700 (LWP 17598)]
operator= (v=..., this=0x7fff858a3d30) at /usr/include/qt4/QtCore/qvector.h:393
393     o->ref.ref();
(gdb) bt
#0  operator= (v=..., this=0x7fff858a3d30)
    at /usr/include/qt4/QtCore/qvector.h:393
#1  song::processNextBuffer (this=0x5427a50)
    at /home/h/Lataukset/git/grejppi-lmms/src/core/song.cpp:204
#2  0x00000000005122e3 in Mixer::renderNextBuffer (this=0xbe8cf0)
    at /home/h/Lataukset/git/grejppi-lmms/src/core/Mixer.cpp:375
#3  0x0000000000512784 in Mixer::fifoWriter::run (this=0x5dfad30)
    at /home/h/Lataukset/git/grejppi-lmms/src/core/Mixer.cpp:953
#4  0x00007ffff685a32f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x00007ffff7bc4182 in start_thread (arg=0x7fff858a4700)
    at pthread_create.c:312
#6  0x00007ffff41d230d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

This is strange because it doesn't look like there's anything related to arpeggio in the backtrace, but only happens when arpeggio is enabled on an instrument...

[diizy]

On 07/14/2014 07:09 PM, grejppi wrote:

Happens here too. Ubuntu 14.04, 64-bit. (Qt 4.8.5)

|Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff858a4700 (LWP 17598)]
operator= (v=..., this=0x7fff858a3d30) at /usr/include/qt4/QtCore/qvector.h:393
393 o->ref.ref();
(gdb) bt
#0 operator= (v=..., this=0x7fff858a3d30)
at /usr/include/qt4/QtCore/qvector.h:393
#1 song::processNextBuffer (this=0x5427a50)
at /home/h/Lataukset/git/grejppi-lmms/src/core/song.cpp:204
#2 0x00000000005122e3 in Mixer::renderNextBuffer (this=0xbe8cf0)
at /home/h/Lataukset/git/grejppi-lmms/src/core/Mixer.cpp:375
#3 0x0000000000512784 in Mixer::fifoWriter::run (this=0x5dfad30)
at /home/h/Lataukset/git/grejppi-lmms/src/core/Mixer.cpp:953
#4 0x00007ffff685a32f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5 0x00007ffff7bc4182 in start_thread (arg=0x7fff858a4700)
at pthread_create.c:312
#6 0x00007ffff41d230d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
|

@grejppi, can you post a full backtrace (bt full)?

I can't really find any obvious fault in song.cpp... It's also perhaps
possible this is a regression in Qt? I have Qt 4.8.2 and I don't
encounter this problem... which Qt version is used for the win binaries?
@tresf?

[grejppi]

@diizy:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff857cc700 (LWP 18115)]
operator= (v=..., this=0x7fff857cbd30)
    at /usr/include/qt4/QtCore/qvector.h:393
393     o->ref.ref();
(gdb) bt full
#0  operator= (v=..., this=0x7fff857cbd30)
    at /usr/include/qt4/QtCore/qvector.h:393
        o = 0x0
#1  song::processNextBuffer (this=0x5427ea0)
    at /home/h/Lataukset/git/grejppi-lmms/src/core/song.cpp:204
        track_list = {{d = 0x7ffff6cc2940 <QVectorData::shared_null>, 
            p = 0x7ffff6cc2940 <QVectorData::shared_null>}}
        tco_num = -1
        tl = <optimized out>
        total_frames_played = <optimized out>
        check_loop = <optimized out>
#2  0x00000000005122e3 in Mixer::renderNextBuffer (this=0xb19520)
    at /home/h/Lataukset/git/grejppi-lmms/src/core/Mixer.cpp:375
        timer = {begin = {tv_sec = 1405355305, tv_usec = 363942}}
        it_rem = <optimized out>
        new_cpu_load = <optimized out>
        last_metro_pos = {<MidiTime> = {m_ticks = -1, 
            static s_ticksPerTact = 192}, m_timeLine = 0x0, 
          m_timeLineUpdate = true, m_currentFrame = 0}
        p = <optimized out>
#3  0x0000000000512784 in Mixer::fifoWriter::run (this=0x5dfa8b0)
    at /home/h/Lataukset/git/grejppi-lmms/src/core/Mixer.cpp:953
        buffer = 0x7fff6c004f30
        b = <optimized out>
#4  0x00007ffff685a32f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
No symbol table info available.
#5  0x00007ffff7bc4182 in start_thread (arg=0x7fff857cc700)
    at pthread_create.c:312
        __res = <optimized out>
        pd = 0x7fff857cc700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735432935168, 
                5552181362477150207, 1, 0, 140735432935872, 140735432935168, 
                -5552299038092644353, -5552198434512654337}, 
              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"
#6  0x00007ffff41d230d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

[diizy]

Ok, this is looking like a really tricky issue.

What I've gathered so far (by looking through both LMMS & Qt source code):

• The problem is somewhere in song::processNextBuffer.
• Somewhere in that method, we're assigning a QVector to a QVector
  (as indicated by the operator= in qvector.h)
• Probably the argument of the assignment is an invalid or null pointer,
  possibly an uninitialized variable: this is indicated by the "o" pointer
  being null
• The "o" is an internal variable of QVector, which gets to some weird
  black magic and data structures that I'm not even going to attempt to
  understand completely

So. The million dollar question here is, why does this only happen when
arpeggio is enabled? If the problem is with arpeggio, then I'd expect
the error to be thrown from somewhere like NotePlayHandle,
InstrumentFunctions, etc. Not song. Arpeggio status of an instrument
shouldn't affect the song class in any way...

It's very hard for me to attempt to fix this since I can't reproduce the
bug, but I'll do my best...

@grejppi, could you maybe try to track down the exact spot where the
error happens? Add some qDebug() calls to song::processNextBuffer(),
then see how far it runs before crashing...

[grejppi]

Hmm. This happens in master, not in stable-1.1.

[tresf]

which Qt version is used for the win binaries? @tresf?

4.8.7~snapshot-1, according to ~tobydox/mingw

I looked at the source for qvector.cpp, qvector.h but had difficulties navigating to any changes after 4.8.7.

[tresf]

@musikBear, please re-upload the offending track, or close out this bug if it is no longer valid. The link you provided is no longer available.

I'd also recommend using the mmp file extension and hosting on Gist so that we aren't redirected to the ever-so-virus-malware-prone sendspace per:

[tresf]

Hmm. This happens in master, not in stable-1.1.

The backtrace @grejppi provided and the original bug report conflict as they are from different branches.

Closing this specific bug out as invalid since no one else has been able to reproduce what @musikBear is reporting on the branch he was using at the time of bug creation.

That said, @grejppi's/@diizy's QVector research for the master branch is still relevant, so we may need to cross-reference some of the relevant comments in a future bug.