Odd crash (is it CppSupportPart or ProblemReporter at fault?)

Fri Dec 15 00:07:38 UTC 2006

Andras Mantia wrote:
> On Friday 15 December 2006 00:02, Matthew Woehlke wrote:
>> ...looks like m_mutex did not initialize? Does that mean anything to
>> anyone, or does it just look like a valgrind-induced error?
> 
> This makes me worry (OK, the quotation is broken). It seems my suspicion 
> is true, and (re)entering the eventloop causes a timer to be activated 
> which finds the CppSupportPart in a wrong state.

Yes, it does look that way:

> ==21821== Invalid read of size 4
> ==21821==    at 0x75C2C09: QMutex::lock() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x37283917: BackgroundParser::lock() (backgroundparser.h:59)
> ==21821==    by 0x372D380F: CppSupportPart::slotSaveMemory() (cppsupportpart.cpp:1027)
> ==21821==    by 0x372DEC07: CppSupportPart::qt_invoke(int, QUObject*) (cppsupportpart.moc:279)
> ==21821==    by 0x733044F: QObject::activate_signal(QConnectionList*, QUObject*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x7330B29: QObject::activate_signal(int) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x766329C: QTimer::timeout() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x735015B: QTimer::event(QEvent*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72D18F8: QApplication::internalNotify(QObject*, QEvent*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72D1A89: QApplication::notify(QObject*, QEvent*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x354F845F: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
> ==21821==    by 0x72C5C6D: QEventLoop::activateTimers() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x7281C2D: QEventLoop::processEvents(unsigned) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72E6F24: QEventLoop::enterLoop() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72D0B20: QApplication::enter_loop() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x3428E005: BlockingKProcess::enter_loop() (blockingkprocess.cpp:97)
> ==21821==    by 0x3428DE21: BlockingKProcess::start(KProcess::RunMode, KProcess::Communication) (blockingkprocess.cpp:57)
> ==21821==    by 0x372F9B59: SetupHelper::getGccIncludePath(bool*) (setuphelper.cpp:27)
> ==21821==    by 0x372EFB02: KDevDriver::setup() (kdevdriver.cpp:79)
> ==21821==    by 0x372EF583: KDevDriver::KDevDriver(CppSupportPart*) (kdevdriver.cpp:14)
> ==21821==    by 0x37254FED: BackgroundParser::BackgroundParser(CppSupportPart*, QWaitCondition*) (backgroundparser.cpp:240)
> ==21821==    by 0x372CF327: CppSupportPart::projectOpened() (cppsupportpart.cpp:463)
> ==21821==    by 0x372DE887: CppSupportPart::qt_invoke(int, QUObject*) (cppsupportpart.moc:249)
> ==21821==    by 0x73303D8: QObject::activate_signal(QConnectionList*, QUObject*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x7330B29: QObject::activate_signal(int) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x3424FE52: KDevCore::projectOpened() (kdevcore.moc:115)
> ==21821==    by 0x341BD059: Core::doEmitProjectOpened() (core.h:47)
> ==21821==    by 0x341BA39C: ProjectManager::slotLoadProject() (projectmanager.cpp:299)
> ==21821==    by 0x341BC83A: ProjectManager::qt_invoke(int, QUObject*) (projectmanager.moc:119)
> ==21821==    by 0x733044F: QObject::activate_signal(QConnectionList*, QUObject*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x766156C: QSignal::signal(QVariant const&) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x734918C: QSignal::activate() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x735024A: QSingleShotTimer::event(QEvent*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72D18F8: QApplication::internalNotify(QObject*, QEvent*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72D1A89: QApplication::notify(QObject*, QEvent*) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x354F845F: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:550)
> ==21821==    by 0x72C5C6D: QEventLoop::activateTimers() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x7281C2D: QEventLoop::processEvents(unsigned) (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72E6F24: QEventLoop::enterLoop() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72E6E7D: QEventLoop::exec() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x72D0AFA: QApplication::exec() (in /usr/lib/qt-3.3/lib/libqt-mt.so.3.3.3)
> ==21821==    by 0x804EE8C: main (main.cpp:149)
> ==21821==  Address 0x2F737098 is not stack'd, malloc'd or (recently) free'd

...that is indeed a method being called _while_ the constructor is on 
the stack. Oops. So, the real question is, could that be the cause of 
all the previous crashes I saw?

> [snip] ... but I wonder why is this code called more than once as 
> usually you don't change the compiler under KDevelop. So the easiest 
> solution to avoid this crash whould be to execute gcc with the various 
> arguments only once for every project , cache the results and reuse it. 

Eh? Um, I start KDevelop with --profile CandCppIDE and I see that it 
switches profiles to KDE???IDE (sorry, forget the exact name) because it 
is loading the last-opened project. Might that be a problem somehow? 
Otherwise I am not sure what you mean about 'changing the compiler'. If 
you mean building KDevelop, the last I recall was doing a 'make clean' 
so nothing about the build environment should have changed while 
building. Unless you mean KDevelop vs. the rest of KDE which could well 
be different?

> If this is already the case, than the other solutions are:
> - try to see why and what timer is triggered and disable it before using 
> BlockingKProcess

Um... Any tips on how to do that? I'm not that familiar with Qt events 
and such.

> - fix the CppSupportPart::slotSaveMemory to deal with this case

That seems like the solution I would have come up with. Something like 
'don't do this while my constructor is running'. It's on the second line 
of constructor so this should be feasible.

> - don't use BlockingKProcess (well, not nice as it will give us a hang 
> when loading projects with a disabled Konsole plugin...)

Agreed, probably not the best solution.

-- 
Matthew
What? This signature /again/?