Menu
▾
▴
[Valgrind-users] helgrind: race with no other thread ?
|
From: David F. <fa...@kd...> - 2013-06-22 09:48:58
|
Hello, I have just had another case of a helgrind data race report with only one backtrace instead of two... How can there be a race with only one contestant? $ helgrind /d/kde/inst/kde4.10/bin/kactivitymanagerd --nocrashhandler --nofork [snip debug output] ==11756== ---------------------------------------------------------------- ==11756== ==11756== Lock at 0x1191B6B0 was first observed ==11756== at 0x4C2C548: QMutex_constructor_WRK (hg_intercepts.c:2246) ==11756== by 0x4C309F8: QMutex::QMutex(QMutex::RecursionMode) (hg_intercepts.c:2252) ==11756== by 0x7238F2A: QMutexPool::createMutex(int) (qmutexpool.cpp:138) ==11756== by 0x7239051: QMutexPool::get(void const*) (qmutexpool_p.h:76) ==11756== by 0x7390A14: signalSlotLock(QObject const*) (qobject.cpp:111) ==11756== by 0x7397518: QMetaObjectPrivate::connect(QObject const*, int, QObject const*, int, QMetaObject const*, int, int*) (qobject.cpp:3162) ==11756== by 0x7396085: QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2650) ==11756== by 0x4200D3: Resources::Resources(QObject*) (Resources.cpp:305) ==11756== by 0x4160D4: Resources* runInQThread<Resources>() (Application.cpp:57) ==11756== by 0x415D40: Application::Private::Private() (Application.cpp:88) ==11756== by 0x4162E3: kamd::utils::d_ptr<Application::Private>::d_ptr() (d_ptr_implementation.h:29) ==11756== by 0x4140F0: Application::Application() (Application.cpp:107) ==11756== by 0x415019: Application::self() (Application.cpp:208) ==11756== by 0x4152C2: main (Application.cpp:242) ==11756== ==11756== Possible data race during read of size 8 at 0x11923F40 by thread #1 ==11756== Locks held: 1, at address 0x1191B6B0 ==11756== at 0x7398617: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3498) ==11756== by 0x57B5924: KWindowSystem::activeWindowChanged(unsigned long) (kwindowsystem.moc:156) ==11756== by 0x57B105C: KWindowSystemPrivate::x11Event(_XEvent*) (kwindowsystem_x11.cpp:197) ==11756== by 0x566F049: KEventHackWidget::publicX11Event(_XEvent*) (ksystemeventfilter.cpp:43) ==11756== by 0x566ECBB: KSystemEventFilterPrivate::filterEvent(void*) (ksystemeventfilter.cpp:102) ==11756== by 0x566EC29: _k_eventFilter(void*) (ksystemeventfilter.cpp:91) ==11756== by 0x73680F5: QAbstractEventDispatcher::filterEvent(void*) (qabstracteventdispatcher.cpp:542) ==11756== by 0x7CC5EFE: QEventDispatcherX11::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_x11.cpp:128) ==11756== by 0x7376C97: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:149) ==11756== by 0x7376E2B: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:204) ==11756== by 0x7379FD5: QCoreApplication::exec() (qcoreapplication.cpp:1221) ==11756== by 0x7BE4E97: QApplication::exec() (qapplication.cpp:3823) ==11756== by 0x4152C7: main (Application.cpp:242) ==11756== ==11756== Address 0x11923F40 is 16 bytes inside a block of size 104 alloc'd ==11756== at 0x4C2BA9B: operator new(unsigned long) (vg_replace_malloc.c:319) ==11756== by 0x7239F6B: QThreadPrivate::QThreadPrivate(QThreadData*) (qthread.cpp:190) ==11756== by 0x723A148: QThread::QThread(QObject*) (qthread.cpp:408) ==11756== by 0x416D66: Resources* runInQThread<Resources>()::Thread::Thread(Resources*) (Application.cpp:62) ==11756== by 0x4160F4: Resources* runInQThread<Resources>() (Application.cpp:75) ==11756== by 0x415D40: Application::Private::Private() (Application.cpp:88) ==11756== by 0x4162E3: kamd::utils::d_ptr<Application::Private>::d_ptr() (d_ptr_implementation.h:29) ==11756== by 0x4140F0: Application::Application() (Application.cpp:107) ==11756== by 0x415019: Application::self() (Application.cpp:208) ==11756== by 0x4152C2: main (Application.cpp:242) ==11756== valgrind-3.9.0.SVN, freshly updated. -- David Faure, fa...@kd..., http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 |
