Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Segfault when job queue is full #777

Closed
diizy opened this issue May 27, 2014 · 15 comments
Closed

Segfault when job queue is full #777

diizy opened this issue May 27, 2014 · 15 comments
Labels
bug
Milestone
1.2.0

Comments

@diizy
Copy link
Contributor

diizy commented May 27, 2014

Just documenting the backtrace here for future reference

#0  operator= (this=0xb32ca1a0, value=0xaac05e90) at /usr/include/qt4/QtCore/qbasicatomic.h:182
No locals.
#1  operator= (value=0xaac05e90, this=0xb32ca1a0) at /usr/include/qt4/QtCore/qatomic.h:145
No locals.
#2  MixerWorkerThread::JobQueue::addJob (this=0x82ad700, _job=0xaac05e90)
    at /home/vesa/tmp/lmms-ui/src/core/MixerWorkerThread.cpp:53
No locals.
#3  0x08173e57 in addJob (_job=<optimized out>) at /home/vesa/tmp/lmms-ui/include/MixerWorkerThread.h:86
No locals.
#4  fillJobQueue<QList<PlayHandle*> > (_opMode=MixerWorkerThread::JobQueue::Static, _vec=...)
    at /home/vesa/tmp/lmms-ui/include/MixerWorkerThread.h:98
        it = <optimized out>
#5  Mixer::renderNextBuffer (this=0x89d1ed8) at /home/vesa/tmp/lmms-ui/src/core/Mixer.cpp:380
        timer = {begin = {tv_sec = 1401133078, tv_usec = 755525}}
        it_rem = {i = 0xaac03298}
        last_metro_pos = {<MidiTime> = {m_ticks = -1, static s_ticksPerTact = 192}, m_timeLine = 0x0, 
          m_timeLineUpdate = true, m_currentFrame = 0}
        p = {<MidiTime> = {m_ticks = <optimized out>, static s_ticksPerTact = 192}, m_timeLine = <optimized out>, 
          m_timeLineUpdate = 152, m_currentFrame = 0}
#6  0x08174437 in Mixer::fifoWriter::run (this=0x8e9ed80) at /home/vesa/tmp/lmms-ui/src/core/Mixer.cpp:952
        buffer = 0xaac020e8
        b = <optimized out>
#7  0xb696eeb0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
No symbol table info available.
#8  0xb7701d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
No symbol table info available.
#9  0xb6186bae in clone () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
@diizy diizy changed the title Master branch: segfault during playback 1.1 branch: segfault during playback Jun 11, 2014
@diizy diizy added this to the 1.1.0 milestone Jun 11, 2014
@diizy
Copy link
Contributor Author

diizy commented Jun 11, 2014

Another crash... this seems to happen with arpeggiator, when tweaking the knobs while the instrument is playing.

#0  0xb69afa0e in ?? () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#1  0xb6bb851f in operator delete(void*) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#2  0x0820e0e4 in NotePlayHandle::~NotePlayHandle (this=0xab7030e0, __in_chrg=<optimized out>)
    at /home/vesa/tmp/lmms-ui/src/core/NotePlayHandle.cpp:145
No locals.
#3  0x0820daf6 in play (_working_buffer=0x0, this=0x8c0e798) at /home/vesa/tmp/lmms-ui/src/core/NotePlayHandle.cpp:266
        it = {i = 0x8c11c1c}
#4  NotePlayHandle::play (this=0x8c0e798, _working_buffer=0x0)
    at /home/vesa/tmp/lmms-ui/src/core/NotePlayHandle.cpp:183
No locals.
#5  0x08190e17 in PlayHandle::doProcessing (this=0x8c0e798, buffer=0x0)
    at /home/vesa/tmp/lmms-ui/include/PlayHandle.h:79
No locals.
#6  0xb289d211 in process (workingBuffer=0x0, this=0x8c0e798) at /home/vesa/tmp/lmms-ui/include/ThreadableJob.h:69
No locals.
#7  InstrumentPlayHandle::play (this=0x8afc538, _working_buffer=0x859d910)
    at /home/vesa/tmp/lmms-ui/include/InstrumentPlayHandle.h:64
        nph = 0x8c0e798
        cnph = 0x8c0e798
        _container_ = {c = {{p = {static shared_null = {ref = {_q_value = 6412}, alloc = 0, begin = 0, end = 0, 
                  sharable = 1, array = {0x0}}, d = 0xab7031f0}, d = 0xab7031f0}}, brk = 0, i = {i = 0xab703208}, e = {
            i = 0xab70320c}}
        nphv = {{p = {static shared_null = {ref = {_q_value = 6412}, alloc = 0, begin = 0, end = 0, sharable = 1, 
                array = {0x0}}, d = 0xab7031f0}, d = 0xab7031f0}}
#8  0x08190e17 in PlayHandle::doProcessing (this=0x8afc538, buffer=0x859d910)
---Type <return> to continue, or q <return> to quit---
    at /home/vesa/tmp/lmms-ui/include/PlayHandle.h:79
No locals.
#9  0x081ecb05 in process (workingBuffer=<optimized out>, this=0x8afc538)
    at /home/vesa/tmp/lmms-ui/include/ThreadableJob.h:69
No locals.
#10 MixerWorkerThread::JobQueue::run (this=0x82d2720, _buffer=0x859d910)
    at /home/vesa/tmp/lmms-ui/src/core/MixerWorkerThread.cpp:70
        i = <optimized out>
        processedJob = <optimized out>
#11 0x081ece96 in MixerWorkerThread::startAndWaitForJobs ()
    at /home/vesa/tmp/lmms-ui/src/core/MixerWorkerThread.cpp:146
No locals.
#12 0x08182552 in Mixer::renderNextBuffer (this=0x8519150) at /home/vesa/tmp/lmms-ui/src/core/Mixer.cpp:381
        timer = {begin = {tv_sec = 1402502355, tv_usec = 253226}}
        it_rem = {i = 0xab702884}
        last_metro_pos = {<MidiTime> = {m_ticks = -1, static s_ticksPerTact = 192}, m_timeLine = 0x0, 
          m_timeLineUpdate = true, m_currentFrame = 0}
        p = {<MidiTime> = {m_ticks = <optimized out>, static s_ticksPerTact = 192}, m_timeLine = <optimized out>, 
          m_timeLineUpdate = 132, m_currentFrame = 0}
#13 0x08182b97 in Mixer::fifoWriter::run (this=0x8999b10) at /home/vesa/tmp/lmms-ui/src/core/Mixer.cpp:952
        buffer = 0xab7033a8
        b = <optimized out>
#14 0xb7210eb0 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
No symbol table info available.
#15 0xb7fa3d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
No symbol table info available.
#16 0xb6a28bae in clone () from /lib/i386-linux-gnu/libc.so.6
---Type <return> to continue, or q <return> to quit---

@zonkmachine
Copy link
Member

On commit 66c05f6

Ubuntustudio 12.04
Kernel Linux 3.2.0-64-lowlatency
libqt4 4:4.8.1-0ubuntu4.8

this seems to happen with arpeggiator, when tweaking the knobs while the instrument is playing.

But that's all I'm doing nowadays, tweaking arpeggiator knobs live, and I've never seen a crash like that. I'll try and make it go down bad but so far nothing remotely suspicious going on.

@diizy
Copy link
Contributor Author

diizy commented Jun 11, 2014

On 06/11/2014 10:06 PM, Oskar Wallgren wrote:

On commit 66c05f6
66c05f6

|Ubuntustudio 12.04
Kernel Linux 3.2.0-64-lowlatency
libqt4 4:4.8.1-0ubuntu4.8
|

this seems to happen with arpeggiator, when tweaking the knobs
while the instrument is playing.

But that's all I'm doing nowadays, tweaking arpeggiator knobs live,
and I've never seen a crash like that. I'll try and make it go down
bad but so far nothing remotely suspicious going on.

Easier to trigger it when you turn the speed all the way up to 25ms and
then just change the other settings during playback.

@zonkmachine
Copy link
Member

Easier to trigger it when you turn the speed all the way up to 25ms and then just change the other settings during playback.

Nope. 25ms works just fine. Short notes. Long notes. Overlapping notes.

@diizy
Copy link
Contributor Author

diizy commented Jun 11, 2014

On 06/11/2014 10:35 PM, Oskar Wallgren wrote:

Easier to trigger it when you turn the speed all the way up to
25ms and then just change the other settings during playback.

Nope. 25ms works just fine. Short notes. Long notes. Overlapping notes.

Ok, try it with LB302... might be I still have some issues unsolved there.

@diizy
Copy link
Contributor Author

diizy commented Jun 12, 2014

Funny, after I recompiled from stable-1.1, now I can't seem to trigger it either... wonder what happened?

@diizy
Copy link
Contributor Author

diizy commented Jun 12, 2014

Oh wait, now I can again.

It's easiest to reproduce like this: enable both stacking + arpeggio, should crash pretty quickly.

Problem is I can't get a backtrace: it just shows this

#0  0x0a959070 in ?? ()
#1  0x0a9d3f90 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

@diizy
Copy link
Contributor Author

diizy commented Jun 28, 2014

I think this is probably solved now. Will reopen if this happens again in 1.1.

@diizy diizy closed this as completed Jun 28, 2014
@lukas-w
Copy link
Member

lukas-w commented Aug 27, 2017 •
edited
Loading

I get a crash similar to this one when rendering the project from #3223 after increasing the buffer size (BM_INITIAL_BUFFERS). In this line:

lmms/src/core/MixerWorkerThread.cpp

Line 57 in efd0d34

m_items[m_queueSize.fetchAndAddOrdered(1)] = _job;

m_queueSize overflows resulting in the segfault. m_queueSize grows larger than 1024, which is m_items' size.

1  std::__atomic_base<ThreadableJob *>::store                 atomic_base.h         691 0x1001afd3e    
2  std::atomic<ThreadableJob *>::store                        atomic                443 0x1001afd3e    
3  QAtomicOps<ThreadableJob *>::storeRelease<ThreadableJob *> qatomic_cxx11.h       257 0x1001afc92    
4  QBasicAtomicPointer<ThreadableJob>::storeRelease           qbasicatomic.h        245 0x1001afc3d    
5  QAtomicPointer<ThreadableJob>::operator=                   qatomic.h             188 0x1001af957    
6  MixerWorkerThread::JobQueue::addJob                        MixerWorkerThread.cpp 57  0x1001af32b    
7  MixerWorkerThread::addJob                                  MixerWorkerThread.h   87  0x100187e9f    
8  MixerWorkerThread::fillJobQueue<QList<PlayHandle *>>       MixerWorkerThread.h   99  0x1001aa53c    
9  Mixer::renderNextBuffer                                    Mixer.cpp             438 0x1001a873a    
10 Mixer::nextBuffer                                          Mixer.h               298 0x1001aaf68    
11 AudioDevice::getNextBuffer                                 AudioDevice.cpp       84  0x1001f2c8d    
12 AudioDevice::processNextBuffer                             AudioDevice.cpp       67  0x1001f2bdd    
13 ProjectRenderer::run                                       ProjectRenderer.cpp   195 0x1001c589e    
14 ??                                                                                   0x7ffff408015b 
15 start_thread                                                                         0x7ffff7bc2049 
16 clone                                                                                0x7ffff377cf0f

@lukas-w lukas-w reopened this Aug 27, 2017
@lukas-w lukas-w added the bug label Aug 27, 2017
@lukas-w lukas-w removed this from the 1.1.0 milestone Aug 27, 2017
@lukas-w lukas-w mentioned this issue Sep 17, 2017
Merged
@lukas-w lukas-w changed the title 1.1 branch: segfault during playback Segfault when job queue is full Sep 26, 2017
@lukas-w lukas-w added this to the 1.2.0 milestone Sep 26, 2017
@PhysSong
Copy link
Member

I think implementing thread safe and extendable queue will resolve this problem. However, I wonder if there would be some performance issues.
Another way is waiting until job queue isn't full and then queue the job. IDK which would be better...

@PhysSong PhysSong mentioned this issue Oct 15, 2017
Closed
@PhysSong
Copy link
Member

implementing thread safe and extendable queue

Boost has a lock-free queue implementation, but I remember there were problems with finding Boost in CMake scripts. Could we somehow (re-)implement the algorithm or something similar?

@simonvanderveldt
Copy link
Contributor

Boost has a lock-free queue implementation, but I remember there were problems with finding Boost in CMake scripts. Could we somehow (re-)implement the algorithm or something similar?

@PhysSong A way to find Boost has been included with CMake for quiet some tie, are you sure there are issues with it?

@PhysSong
Copy link
Member

PhysSong commented Apr 1, 2018

@PhysSong A way to find Boost has been included with CMake for quiet some tie, are you sure there are issues with it?

@lukas-w have tried to use that in #3783, but failed.

@simonvanderveldt
Copy link
Contributor

simonvanderveldt commented Apr 1, 2018 •
edited
Loading

@PhysSong Are you sure? I don't see any reference to that in that PR, only that the PR used Boost but then it got removed because it was no longer necessary. His commit for adding Boost seems to be correct as well, but I might be missing something.
If anyone wants to try fixing this bug and needs Boost for it it should be enough to use the changes in that commit.

@lukas-w
Copy link
Member

lukas-w commented Apr 1, 2018

@simonvanderveldt If I recall correctly, the troubles I had were with the MinGW build. Here's a link to the last Travis build before I abolished the idea of using Boost: https://travis-ci.org/LMMS/lmms/builds/269638905

It's definitely doable with Boost, I just couldn't be bothered with fixing it for cross-compiling back then.

@lukas-w lukas-w mentioned this issue Apr 29, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
1.2.0
Development

No branches or pull requests
5 participants
@simonvanderveldt @lukas-w @diizy @zonkmachine @PhysSong