segfault on skin change

[RJ Skerry-Ryan]

Once and a while I'll get a crash on skin change ever since I introduced templates, etc. I managed to grab a backtrace on an unoptimized build today:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000015fbfe108
0x000000010051ab03 in ControlObjectThread::qt_static_metacall (_o=0x10831e828, _c=QMetaObject::InvokeMetaMethod, _id=5, _a=0x7fff5fbfe0e0) at osx64_build/moc_controlobjectthread.cc:63
63 case 5: _t->slotValueChanged((*reinterpret_cast< double(*)>(_a[1])),(*reinterpret_cast< QObject*(*)>(_a[2]))); break;
(gdb) thread apply all bt

Thread 31 (process 27914):
#0 0x00007fff9022a6d6 in __workq_kernreturn ()
#1 0x00007fff87f0cf1c in _pthread_workq_return ()
#2 0x00007fff87f0cce3 in _pthread_wqthread ()
#3 0x00007fff87ef7191 in start_wqthread ()

Thread 30 (process 27914):
#0 0x00007fff9022a6d6 in __workq_kernreturn ()
#1 0x00007fff87f0cf1c in _pthread_workq_return ()
#2 0x00007fff87f0cce3 in _pthread_wqthread ()
#3 0x00007fff87ef7191 in start_wqthread ()

Thread 29 (process 27914):
#0 0x00007fff9022a6d6 in __workq_kernreturn ()
#1 0x00007fff87f0cf1c in _pthread_workq_return ()
#2 0x00007fff87f0cce3 in _pthread_wqthread ()
#3 0x00007fff87ef7191 in start_wqthread ()

Thread 27 (process 27914):
#0 0x00007fff90228686 in mach_msg_trap ()
#1 0x00007fff90227c42 in mach_msg ()
#2 0x0000000103291970 in XServerMachPort::ReceiveMessage ()
#3 0x00000001032adb23 in MIDIProcess::RunMIDIInThread ()
#4 0x0000000103292c2c in XThread::RunHelper ()
#5 0x000000010329280f in CAPThread::Entry ()
#6 0x00007fff87f0a772 in _pthread_start ()
#7 0x00007fff87ef71a1 in thread_start ()

Thread 26 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x00000001023c6ff7 in QTWTF::TCMalloc_PageHeap::scavengerThread ()
#3 0x00000001023c709b in QTWTF::TCMalloc_PageHeap::runScavengerThread ()
#4 0x00007fff87f0a772 in _pthread_start ()
#5 0x00007fff87ef71a1 in thread_start ()

Thread 25 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x12101b790) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 24 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x11ae2a860) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 23 (process 27914):
#0 0x00007fff90228686 in mach_msg_trap ()
#1 0x00007fff90227c42 in mach_msg ()
#2 0x00007fff913c170c in HALB_MachPort::SendMessageWithReply ()
#3 0x00007fff913c169a in HALB_MachPort::SendSimpleMessageWithSimpleReply ()
#4 0x00007fff913bfad9 in HALC_ProxyIOContext::IOWorkLoop ()
#5 0x00007fff913bf5bf in HALC_ProxyIOContext::IOThreadEntry ()
#6 0x00007fff913bf497 in HALB_IOThread::Entry ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 22 (process 27914):
#0 0x00007fff90228686 in mach_msg_trap ()
#1 0x00007fff90227c42 in mach_msg ()
#2 0x00007fff913c170c in HALB_MachPort::SendMessageWithReply ()
#3 0x00007fff913c169a in HALB_MachPort::SendSimpleMessageWithSimpleReply ()
#4 0x00007fff913bfad9 in HALC_ProxyIOContext::IOWorkLoop ()
#5 0x00007fff913bf5bf in HALC_ProxyIOContext::IOThreadEntry ()
#6 0x00007fff913bf497 in HALB_IOThread::Entry ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 21 (process 27914):
#0 0x00007fff90228686 in mach_msg_trap ()
#1 0x00007fff90227c42 in mach_msg ()
#2 0x00007fff913c170c in HALB_MachPort::SendMessageWithReply ()
#3 0x00007fff913c169a in HALB_MachPort::SendSimpleMessageWithSimpleReply ()
#4 0x00007fff913bfad9 in HALC_ProxyIOContext::IOWorkLoop ()
#5 0x00007fff913bf5bf in HALC_ProxyIOContext::IOThreadEntry ()
#6 0x00007fff913bf497 in HALB_IOThread::Entry ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 20 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x000000010061081b in VSyncThread::run (this=0x1178896d0) at src/waveform/vsyncthread.cpp:68
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 19 (process 27914):
#0 0x00007fff9022a322 in select$DARWIN_EXTSN ()
#1 0x0000000101275236 in qt_safe_select ()
#2 0x0000000101279844 in QEventDispatcherUNIXPrivate::doSelect ()
#3 0x0000000101279c20 in QEventDispatcherUNIX::processEvents ()
#4 0x0000000101248c58 in QEventLoop::exec ()
#5 0x00000001011536c6 in QThread::exec ()
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 18 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x000000010006682f in AnalyserQueue::dequeueNextBlocking (this=0x113bf8dc0) at src/analyserqueue.cpp:118
#5 0x000000010006765e in AnalyserQueue::run (this=0x113bf8dc0) at src/analyserqueue.cpp:279
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 17 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x00000001003fcd67 in BrowseThread::run (this=0x104071840) at src/library/browse/browsethread.cpp:82
#5 0x000000010115646a in QThreadPrivate::start ()
#6 0x00007fff87f0a772 in _pthread_start ()
#7 0x00007fff87ef71a1 in thread_start ()

Thread 16 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x10856a390) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 15 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x11540d3c0) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 14 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x113b6e280) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 13 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x11287db50) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 12 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x10458d340) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 11 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x10a9c1700) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 10 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000101152db3 in QSemaphore::acquire ()
#5 0x0000000100086696 in CachingReaderWorker::run (this=0x109001c70) at src/cachingreaderworker.cpp:124
#6 0x000000010115646a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 9 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x00000001005e9511 in VinylControlProcessor::run (this=0x10a95d7c0) at src/vinylcontrol/vinylcontrolprocessor.cpp:130
#5 0x000000010115646a in QThreadPrivate::start ()
#6 0x00007fff87f0a772 in _pthread_start ()
#7 0x00007fff87ef71a1 in thread_start ()

Thread 8 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x000000010039473e in EngineSideChain::run (this=0x10456f7f0) at src/engine/sidechain/enginesidechain.cpp:93
#5 0x000000010115646a in QThreadPrivate::start ()
#6 0x00007fff87f0a772 in _pthread_start ()
#7 0x00007fff87ef71a1 in thread_start ()

Thread 7 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x0000000100373357 in EngineWorkerScheduler::run (this=0x104527b30) at src/engine/engineworkerscheduler.cpp:43
#5 0x000000010115646a in QThreadPrivate::start ()
#6 0x00007fff87f0a772 in _pthread_start ()
#7 0x00007fff87ef71a1 in thread_start ()

Thread 6 (process 27914):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010115719c in QWaitConditionPrivate::wait ()
#3 0x0000000101156ea5 in QWaitCondition::wait ()
#4 0x00000001005dcfae in StatsManager::run (this=0x104530930) at src/util/statsmanager.cpp:97
#5 0x000000010115646a in QThreadPrivate::start ()
#6 0x00007fff87f0a772 in _pthread_start ()
#7 0x00007fff87ef71a1 in thread_start ()

Thread 2 (process 27914):
#0 0x00007fff9022ad16 in kevent ()
#1 0x00007fff93c37dea in _dispatch_mgr_invoke ()
#2 0x00007fff93c379ee in _dispatch_mgr_thread ()

Thread 1 (process 27914):
#0 0x000000010051ab03 in ControlObjectThread::qt_static_metacall (_o=0x10831e828, _c=QMetaObject::InvokeMetaMethod, _id=5, _a=0x7fff5fbfe0e0) at osx64_build/moc_controlobjectthread.cc:63
#1 0x0000000101261221 in QMetaObject::activate ()
#2 0x00000001000961aa in ControlDoublePrivate::valueChanged (this=0x10a95ea20, _t1=0, _t2=0x7fff5fbfe350) at osx64_build/control/moc_control.cc:101
#3 0x0000000100091a2e in ControlDoublePrivate::setInner (this=0x10a95ea20, value=0, pSender=0x7fff5fbfe350) at src/control/control.cpp:137
#4 0x000000010009196c in ControlDoublePrivate::set (this=0x10a95ea20, value=0, pSender=0x7fff5fbfe350) at src/control/control.cpp:123
#5 0x0000000100102b01 in ControlObjectThread::set (this=0x7fff5fbfe350, v=0) at src/controlobjectthread.cpp:73
#6 0x0000000100102a93 in ControlObjectThread::slotSet (this=0x7fff5fbfe350, v=0) at src/controlobjectthread.cpp:68
#7 0x0000000100568c9e in LegacySkinParser::parseSkin (this=0x7fff5fbfe4c8, skinPath=@0x7fff5fbfe4b0, pParent=0x104093880) at src/skin/legacyskinparser.cpp:263
#8 0x0000000100582bc3 in SkinLoader::loadDefaultSkin (this=0x117866290, pParent=0x104093880, pKeyboard=0x10453fe70, pPlayerManager=0x10a95e3b0, pControllerManager=0x113bfaaf0, pLibrary=0x113bdf1d0, pVCMan=0x10a934150) at src/skin/skinloader.cpp:73
#9 0x0000000100512071 in MixxxApp::rebootMixxxView (this=0x104093880) at src/mixxx.cpp:1529
#10 0x0000000100511f0d in MixxxApp::slotDeveloperReloadSkin (this=0x104093880, toggle=false) at src/mixxx.cpp:1323
#11 0x000000010052a570 in MixxxApp::qt_static_metacall (_o=0x104093880, _c=QMetaObject::InvokeMetaMethod, _id=22, _a=0x7fff5fbfe7e8) at osx64_build/moc_mixxx.cc:115
#12 0x0000000101261221 in QMetaObject::activate ()
#13 0x00000001014ec530 in QAction::setChecked ()
#14 0x00000001014ec5e1 in QAction::activate ()
#15 0x00000001014a1677 in -[QCocoaMenuLoader qtDispatcherToQAction:] ()
#16 0x00007fff8dc5a959 in -[NSApplication sendAction:to:from:] ()
#17 0x00007fff8dd9036c in -[NSMenuItem _corePerformAction] ()
#18 0x00007fff8dd9005a in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] ()
#19 0x00007fff8dd8ece0 in -[NSMenu performKeyEquivalent:] ()
#20 0x00007fff8dd8e1a3 in -[NSApplication _handleKeyEquivalent:] ()
#21 0x00007fff8dc4b143 in -[NSApplication sendEvent:] ()
#22 0x00000001014a2702 in -[QNSApplication sendEvent:] ()
#23 0x00007fff8db6121a in -[NSApplication run] ()
#24 0x00000001014ab970 in QEventDispatcherMac::processEvents ()
#25 0x0000000101248c58 in QEventLoop::exec ()
#26 0x000000010124c023 in QCoreApplication::exec ()
#27 0x00000001004ffd53 in main (argc=2, argv=0x7fff5fbff2d0) at src/main.cpp

[RJ Skerry-Ryan (rryan)]

In frame #3,

#3 0x0000000100091a2e in ControlDoublePrivate::setInner (this=0x10a95ea20, value=0, pSender=0x7fff5fbfe350) at src/control/control.cpp:137

ControlDoublePrivate::m_key is [Master],num_samplers.

[RJ Skerry-Ryan (rryan)]

The invalid memory access is at:

0x000000015fbfe108

in this expression:

case 5: _t->slotValueChanged((*reinterpret_cast< double(*)>(_a[1])),(*reinterpret_cast< QObject*(*)>(_a[2]))); break;

_a[1] is 0x000000015fbfe108 (a pointer to the double value argument of slotValueChanged).

Walking up to the signal call in ControlDoublePrivate, where _a is defined on the stack:

void *_a[] = { 0, const_cast<void*>(reinterpret_cast<const void*>(&_t1)), const_cast<void*>(reinterpret_cast<const void*>(&_t2)) };

_a[1] is indeed still 0x000000015fbfe108, but _a[1] is defined here as the address of _t1 and &_t1 is 0x7fff5fbfe108.

So it looks like we have some memory corruption here.

_a[1] was initialized to 0x7fff5fbfe108 and then became 0x15fbfe108 sometime between stack frames #2 and #0. Something wrote a 1 to the high-order DWORD of _a[1]. _a[0] and _a[2] have their expected values, though _a[0] is just 0 so that's not a very good canary.

&_a[1] is 0x7fff5fbfe0e8.

Looking for possible candidates that could have written there. All the other threads appear to be polling though maybe they weren't just before this happened. Another theory is that this is just one of several slots fired for this signal and that the slot invoked before this one did the damage.

[Daniel Schürmann (daschuer)]

For me it looks like we call a slot on of an already deleted Object.

From Qt Docu:
> All signals to and from the object are automatically disconnected, and any pending posted events for the object are removed from the event queue. However, it is often safer to use deleteLater() rather than deleting a QObject subclass directly.

Is there a "Slave" object lightening to [Master],num_samplers which is deleted together with the old skin?

We have
 <attribute config_key="[Master],num_samplers">0</attribute>
in the skins

Or is it here:
https://github.com/mixxxdj/mixxx/blob/7905a7e6454d77f635b97f94758f269ba0e911fb/src/widget/wtracktableview.cpp#L110

If it turns out that this is the problem, we should switch all COs to SmartPointers with a deleteLater()

[RJ Skerry-Ryan (rryan)]

Hm, I think you're right. From frame #0:

(gdb) print *(((QObject*)_t)->d_ptr.d)
$66 = {
  _vptr$QObjectData = 0xc00000012,
  q_ptr = 0xd00000000000000c,
  parent = 0x1083216da,
  children = {
    {
      p = {
        d = 0x6d0075006e7620
      },
      d = 0x6d0075006e7620
    }
  },
  isWidget = 1,
  pendTimer = 1,
  blockSig = 1,
  wasDeleted = 1,
  ownObjectName = 1,
  sendChildEvents = 0,
  receiveChildEvents = 1,
  inEventHandler = 0,
  inThreadChangeEvent = 0,
  hasGuards = 0,
  unused = 7360,
  postedEvents = 7143521,
  metaObject = 0x720065006c0070

See wasDeleted. Though I'm still confused about this invalid memory access that has one DWORD set to 0x1. And shouldn't the meta object not invoke a slot on a wasDeleted QObject? Maybe valgrind would help.

Also, a slot that runs before this crash is this one:
https://github.com/mixxxdj/mixxx/blob/master/src/playermanager.cpp#L189

Here are the log lines leading up to the invalid memory access:
Debug [Main]: Now in rebootMixxxView...
Debug [Main]: ~WTrackTableView()
Debug [Main]: ~DlgTrackInfo()
Debug [Main]: ~WLibraryTableView
Debug [Main]: ~WTrackTableView()
Debug [Main]: ~DlgTrackInfo()
Debug [Main]: ~WLibraryTableView
Debug [Main]: ~DlgAutoDJ()
Debug [Main]: ~WTrackTableView()
Debug [Main]: ~DlgTrackInfo()
Debug [Main]: ~WLibraryTableView
Debug [Main]: ~WTrackTableView()
Debug [Main]: ~DlgTrackInfo()
Debug [Main]: ~WLibraryTableView
Debug [Main]: ~WTrackTableView()
Debug [Main]: ~DlgTrackInfo()
Debug [Main]: ~WLibraryTableView
Debug [Main]: ~WTrackTableView()
Debug [Main]: ~DlgTrackInfo()
Debug [Main]: ~WLibraryTableView
Debug [Main]: Ignoring request to reduce the number of samplers to 0

We also delete the skin instead of calling deleteLater() on its root object now:
https://github.com/mixxxdj/mixxx/blob/master/src/mixxx.cpp#L1516

[RJ Skerry-Ryan (rryan)]

Hm, though it is marked isWidget true which is false for a COT.

[RJ Skerry-Ryan (rryan)]

The ControlDoublePrivate looks normal:

(gdb) print *(((QObject*)this)->d_ptr.d)
$68 = {
  _vptr$QObjectData = 0x1013e6e70,
  q_ptr = 0x10a95ea20,
  parent = 0x0,
  children = {
    {
      p = {
        d = 0x1013e2f80
      },
      d = 0x1013e2f80
    }
  },
  isWidget = 0,
  pendTimer = 0,
  blockSig = 0,
  wasDeleted = 0,
  ownObjectName = 0,
  sendChildEvents = 1,
  receiveChildEvents = 1,
  inEventHandler = 0,
  inThreadChangeEvent = 0,
  hasGuards = 0,
  unused = 0,
  postedEvents = 0,
  metaObject = 0x0
}

[RJ Skerry-Ryan (rryan)]

Actually, I think the COT QObjectData is invalid:

wasDeleted and blockSig won't both be 1 if the QObject destructor ran properly (it sets blockSig to 0 and wasDeleted to 1).

[RJ Skerry-Ryan (rryan)]

And the ControlObjectThread from the skin attribute (stack frame #6) also looks fine:

$94 = {
  _vptr$QObjectData = 0x1013e6e70,
  q_ptr = 0x7fff5fbfe350,
  parent = 0x0,
  children = {
    {
      p = {
        d = 0x1013e2f80
      },
      d = 0x1013e2f80
    }
  },
  isWidget = 0,
  pendTimer = 0,
  blockSig = 0,
  wasDeleted = 0,
  ownObjectName = 0,
  sendChildEvents = 1,
  receiveChildEvents = 1,
  inEventHandler = 0,
  inThreadChangeEvent = 0,
  hasGuards = 0,
  unused = 65806,
  postedEvents = 0,
  metaObject = 0x0
}

[RJ Skerry-Ryan (rryan)]

So, to re-cap -- these are all the num_samplers COs in existence:

CO PlayerManager::m_pCONumSamplers
PlayerManager::slotNumSamplersControlChanged
- immediately sets the CO back to the true number of samplers

COS DlgPrefControls::m_pNumSamplers
DlgPrefControls::slotNumSamplersChanged
- immediately returns since 0 is less than the configured number of samplers

COT LibraryControl::m_numSamplers
LibraryControl::slotNumSamplersChanged
- does nothing since it loops 0 times

COT WTrackTableView::m_pNumSamplers
no attached slot

WTrackTableView is the only class that is created and destroyed with every skin reload.

I'm assuming everything is single-threaded and in the main thread.

1) Developer reload hotkey calls MixxxApp::rebootMixxxView()

2) Old skin is deleted. QObject hierarchy for skin is immediately deleted (QObject::deleteChildren() immediately deletes, it does not call deleteLater()), including WTrackTableView and its m_pNumSamplers COT. Log messages definitively show 6 WTrackTableView destructors running.

All WTrackTableView::m_pNumSamplers COs are deleted at this point and should be removed from all connection lists as per the QObject destructor!

3) LegacySkinParser invoked to load the skin.
4) LegacySkinParses created a stack COT to set num_samplers to 0 as per skin attribute.
5) COT::set(0) -> CDP::set(0, CDP) -> slots fire for valueChanged on all connected CO, COT, COS
6) CO::valueChanged fires, PlayerManager::slotNumSamplersChanged is invoked
4) CO::set(4) -> CDP::set(4, CO)

5) invoke CO/COT/COS slots, including LegacySkinParser's stack-based COT
- PlayerManager CO will emit valueChangedFromEngine which is unused.
- LibraryControl should do nothing
- DlgPrefControls should do nothing
- WTrackTableViews are all deleted at this point so their COTs should not be in the CDP connection list.

6) CO::set(4) exits

A COT, presumably the next (or a subsequent) connection in the CDP's connect list after the CO is invoked:

7) COT::qt_static_metacall is invoked by the CDP QMetaObject.

_a[1] is corrupt, so *_a[1] segfaults.

[RJ Skerry-Ryan (rryan)]

It doesn't make sense that the WTrackTableView COT is the one that we crash delivering the signal to. That COT is deleted before we even call LegacySkinParser and it is removed from connection lists and event queues by its destructor.

Luckily, we have the Library in stack frame #8.

print &pLibrary->m_pLibraryControl->m_numSamplers
$100 = (ControlObjectThread *) 0x10831e828

This is indeed the address of the COT that we are delivering the valueChanged signal to when we crash.

[RJ Skerry-Ryan (rryan)]

Looking at LibraryControl::m_numDecks and LibraryControl::m_numSamplers, m_numSamplers has definitely been trampled somehow. In particular, its parent should be 0x0 like m_numDecks (m_numSamplers never gets a parent). Its vptr and q_ptr fields look corrupt.

(gdb) print *pLibrary->m_pLibraryControl->m_numDecks.d_ptr.d
$110 = {
  _vptr$QObjectData = 0x1013e6e70,
  q_ptr = 0x10831e7f8,
  parent = 0x0,
  children = {
    {
      p = {
        d = 0x1013e2f80
      },
      d = 0x1013e2f80
    }
  },
  isWidget = 0,
  pendTimer = 0,
  blockSig = 0,
  wasDeleted = 0,
  ownObjectName = 0,
  sendChildEvents = 1,
  receiveChildEvents = 1,
  inEventHandler = 0,
  inThreadChangeEvent = 0,
  hasGuards = 0,
  unused = 139266,
  postedEvents = 0,
  metaObject = 0x0
}
(gdb) print *pLibrary->m_pLibraryControl->m_numSamplers.d_ptr.d
$111 = {
  _vptr$QObjectData = 0xc00000012,
  q_ptr = 0xd00000000000000c,
  parent = 0x1083216da,
  children = {
    {
      p = {
        d = 0x6d0075006e7620
      },
      d = 0x6d0075006e7620
    }
  },
  isWidget = 1,
  pendTimer = 1,
  blockSig = 1,
  wasDeleted = 1,
  ownObjectName = 1,
  sendChildEvents = 0,
  receiveChildEvents = 1,
  inEventHandler = 0,
  inThreadChangeEvent = 0,
  hasGuards = 0,
  unused = 7360,
  postedEvents = 7143521,
  metaObject = 0x720065006c0070
}

[RJ Skerry-Ryan (rryan)]

Well, it's 100%-ish reproducible for me using Owen's sync skin and hitting the reload hotkey.

[RJ Skerry-Ryan (rryan)]

Adding print-lines to ControlObjet and ControlObjectThread causes it to go away but it confirms my sequence of events above:

the prints go: this, group, item, value, setter

Debug [Main]: ControlObject::privateValueChanged ControlObject(0x106b212f0) "[Master]" "num_samplers" 0 ControlObjectThread(0x7fff5fbfe350)
Debug [Main]: ControlObject::privateValueChanged ControlObject(0x106b212f0) "[Master]" "num_samplers" 4 ControlObject(0x106b212f0)
Debug [Main]: ControlObjectThread::slotValueChanged ControlObjectThread(0x104272e98) "[Master]" "num_samplers" 4 ControlObject(0x106b212f0)
Debug [Main]: LibraryControl::slotNumSamplersChanged 4
Debug [Main]: ControlObjectThread::slotValueChanged ControlObjectThread(0x7fff5fbfe350) "[Master]" "num_samplers" 4 ControlObject(0x106b212f0)
Debug [Main]: Ignoring request to reduce the number of samplers to 0
Debug [Main]: ControlObjectThread::slotValueChanged ControlObjectThread(0x104272e98) "[Master]" "num_samplers" 0 ControlObjectThread(0x7fff5fbfe350)
Debug [Main]: LibraryControl::slotNumSamplersChanged 0
Debug [Main]: ControlObjectThread::slotValueChanged ControlObjectThread(0x7fff5fbfe350) "[Master]" "num_samplers" 0 ControlObjectThread(0x7fff5fbfe350)

LegacySkinParser COT: 0x7fff5fbfe350
PlayerManager CO: 0x106b212f0
LibraryControl COT: 0x104272e98

(These addresses are for a new run from the one I was originally discussing which is why they are different)

[RJ Skerry-Ryan (rryan)]

Hm, I just got a similar segfault:

Thread 45 (process 56199):
#0 0x00007fff90228686 in mach_msg_trap ()
#1 0x00007fff90227c42 in mach_msg ()
#2 0x00007fff913c170c in HALB_MachPort::SendMessageWithReply ()
#3 0x00007fff913c169a in HALB_MachPort::SendSimpleMessageWithSimpleReply ()
#4 0x00007fff913bfad9 in HALC_ProxyIOContext::IOWorkLoop ()
#5 0x00007fff913bf5bf in HALC_ProxyIOContext::IOThreadEntry ()
#6 0x00007fff913bf497 in HALB_IOThread::Entry ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 41 (process 56199):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010122819c in QWaitConditionPrivate::wait ()
#3 0x0000000101227ea5 in QWaitCondition::wait ()
#4 0x0000000101223db3 in QSemaphore::acquire ()
#5 0x0000000100086cb6 in CachingReaderWorker::run (this=0x131d38390) at src/cachingreaderworker.cpp:124
#6 0x000000010122746a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 40 (process 56199):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010122819c in QWaitConditionPrivate::wait ()
#3 0x0000000101227ea5 in QWaitCondition::wait ()
#4 0x0000000101223db3 in QSemaphore::acquire ()
#5 0x0000000100086cb6 in CachingReaderWorker::run (this=0x13024b050) at src/cachingreaderworker.cpp:124
#6 0x000000010122746a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 39 (process 56199):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010122819c in QWaitConditionPrivate::wait ()
#3 0x0000000101227ea5 in QWaitCondition::wait ()
#4 0x0000000101223db3 in QSemaphore::acquire ()
#5 0x0000000100086cb6 in CachingReaderWorker::run (this=0x12a23a460) at src/cachingreaderworker.cpp:124
#6 0x000000010122746a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 38 (process 56199):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010122819c in QWaitConditionPrivate::wait ()
#3 0x0000000101227ea5 in QWaitCondition::wait ()
#4 0x0000000101223db3 in QSemaphore::acquire ()
#5 0x0000000100086cb6 in CachingReaderWorker::run (this=0x12f22fdf0) at src/cachingreaderworker.cpp:124
#6 0x000000010122746a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 37 (process 56199):
#0 0x00007fff9022a0fa in __psynch_cvwait ()
#1 0x00007fff87f0efb9 in _pthread_cond_wait ()
#2 0x000000010122819c in QWaitConditionPrivate::wait ()
#3 0x0000000101227ea5 in QWaitCondition::wait ()
#4 0x0000000101223db3 in QSemaphore::acquire ()
#5 0x0000000100086cb6 in CachingReaderWorker::run (this=0x12dd43bb0) at src/cachingreaderworker.cpp:124
#6 0x000000010122746a in QThreadPrivate::start ()
#7 0x00007fff87f0a772 in _pthread_start ()
#8 0x00007fff87ef71a1 in thread_start ()

Thread 36 (process 56199):
#0 0x00007fff9022a0fa in __ps...

[RJ Skerry-Ryan (rryan)]

I was dragging a track from the library to deck 2.

[RJ Skerry-Ryan (rryan)]

And it happened on releasing the mouse.

[RJ Skerry-Ryan (rryan)]

Ugh, changing my compiler has an affect on this bug:

Using OS X 10.8.5 XCode 5.0.2 with command line tools.

Repro steps:

1) Load Owen's LateNight Sync skin: https://github.com/ywwg/mixxx/tree/mastersync_skins/res/skins/LateNight1920x1080-4Deck-WXGA
2) Reload with developer-mode reload shortcut.

Segfault happens immediately.

$ clang --version
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

The built-in version of clang triggers the segfault with the above steps 100% of the time.

$ llvm-gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The built-in version of llvm-gcc does NOT trigger the segfault using the repro steps.

I installed the HEAD version of clang from the latest LLVM/Clang git repos:

$ /usr/local/homebrew/opt/llvm/bin/clang --version
clang version 3.5
Target: x86_64-apple-darwin12.5.0
Thread model: posix

And the segfault no longer triggers with the above repro steps. Ugh.

[Daniel Schürmann (daschuer)]

Except from https://bugs.launchpad.net/mixxx/+bug/1269559
I have never seen your segfault on Linux .

[Owen Williams (ywwg)]

did you confirm this is a clang issue? can we close this?

[RJ Skerry-Ryan (rryan)]

I still have no clue. I'm seeing the same bug elsewhere now.

[Owen Williams (ywwg)]

I also have never seen anything like this on linux

[Owen Williams (ywwg)]

(Have you run memcheck?)

[RJ Skerry-Ryan (rryan)]

Yea, I'm fairly sure this is specific to my setup. I can still reproduce it but I think it's caused by a mix of different toolchains / LLVM versions.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7266