Version: 0.6kde (using KDE 4.7.0) OS: MS Windows Stable - every time Reproducible: Didn't try Steps to Reproduce: Select Call Graph tab Actual Results: Crash with bug report dialog Expected Results: Call Graph visualization OS: Windows XP-64 Sp3
Is this self-compiled, or using a prepared binary from somewhere? With kcachegrind sources, there also is a qcachegrind/ directory, which allows to compile a version only depending on Qt. I would be very interested if this shows the same bug. > Actual Results: > Crash with bug report dialog Did the dialog provide some data on the crash, e.g. some call stack pinpointing at the crashing point?
(In reply to comment #1) > Is this self-compiled, or using a prepared binary from somewhere? > > With kcachegrind sources, there also is a qcachegrind/ directory, which > allows to compile a version only depending on Qt. I would be very interested > if this shows the same bug. > > > Actual Results: > > Crash with bug report dialog > > Did the dialog provide some data on the crash, e.g. some call stack > pinpointing at the crashing point? I got binary pack via windows version KDE installer 0.9.9-4. This morning have try it on Windows 7 at my office - the same result - stable crash. Unfortunately I have no ability to experiment with building from sources - all my build tools under Linux - Windows is only for desktop. The text at Developer information tab of crash dialog is: Application: KCachegrind (kcachegrind.EXE), signal: EXCEPTION_ACCESS_VIOLATION [unknown]!ZwWaitForMultipleObjects() [[unknown] @ -1] at 0x7d61d051 [unknown]!RtlSetEnvironmentStrings() [[unknown] @ -1] at 0x7d63f988 [unknown]!FlsSetValue() [[unknown] @ -1] at 0x7d4dfe21 [unknown]!ZwWaitForMultipleObjects() [[unknown] @ -1] at 0x7d61d051 [unknown]!WaitForMultipleObjects() [[unknown] @ -1] at 0x7d4e3e8e [unknown]!QFSFileEngine::fileTime() [[unknown] @ -1] at 0x670e7642 [unknown]![unknown]() [[unknown] @ -1] at 0xffffffffff006aec [unknown]!NtRemoveIoCompletion() [[unknown] @ -1] at 0x7d61c8a0 [unknown]!FlsSetValue() [[unknown] @ -1] at 0x7d4dfe21 [unknown]!ZwReplyWaitReceivePortEx() [[unknown] @ -1] at 0x7d61cbcd [unknown]!I_RpcTransConnectionReallocPacket() [[unknown] @ -1] at 0x7da45eac [unknown]!I_RpcTransConnectionReallocPacket() [[unknown] @ -1] at 0x7da45dd0 [unknown]!I_RpcTransConnectionReallocPacket() [[unknown] @ -1] at 0x7da45e94 [unknown]!FlsSetValue() [[unknown] @ -1] at 0x7d4dfe21 [unknown]!ZwReplyWaitReceivePortEx() [[unknown] @ -1] at 0x7d61cbcd [unknown]!I_RpcTransConnectionReallocPacket() [[unknown] @ -1] at 0x7da45eac [unknown]!I_RpcTransConnectionReallocPacket() [[unknown] @ -1] at 0x7da45dd0 [unknown]!I_RpcTransConnectionReallocPacket() [[unknown] @ -1] at 0x7da45e94 [unknown]!FlsSetValue() [[unknown] @ -1] at 0x7d4dfe21 [unknown]!ZwWaitForMultipleObjects() [[unknown] @ -1] at 0x7d61d051 [unknown]!FlsSetValue() [[unknown] @ -1] at 0x7d4dfe21 [unknown]!QProcess::closeWriteChannel() [[unknown] @ -1] at 0x670a8a11 [unknown]![unknown]() [[unknown] @ -1] at 0x56038b08
(In reply to comment #2) > I got binary pack via windows version KDE installer 0.9.9-4. > This morning have try it on Windows 7 at my office - the same result - stable > crash. Good to know, seems reproducable then... > Unfortunately I have no ability to experiment with building from sources > - all my build tools under Linux - Windows is only for desktop. Same for me :( I can not promise to have time for setting up a KDE build environment any time soon. Perhaps there is somebody else also reading this report? But anyway... > The text at Developer information tab of crash dialog is: > > Application: KCachegrind (kcachegrind.EXE), signal: EXCEPTION_ACCESS_VIOLATION > > [unknown]!QProcess::closeWriteChannel() [[unknown] @ -1] at 0x670a8a11 > [unknown]![unknown]() [[unknown] @ -1] at 0x56038b08 This is the only thread which could have triggered the crash. Perhaps it is already reproducable with the pure Qt versions, where the build environment is easier to set up. Hmm... laying out the call graph needs calling "dot.exe" in the background. Do you have a Windows version of GraphViz installed for that (and in %PATH% or same directory?). Josef
Thanks, Josef, this is solution - with GraphViz works fine. But still strange - why crash, but not warning dialog ? It seems to me to fix it will be simple - only to check if dot.exe process was run successfuly.
(In reply to comment #4) > It seems to me to fix it will be simple - > only to check if dot.exe process was run successfuly. I have all kinds of error checks here, and giving warnings works on Linux. No idea what's different on Windows. I will keep this bug report open until I have some time to check this.
Can you please provide a simple test case that I can use to confirm this bug here?
Yes, shure. The crash take place when Graphviz is not installed in case of selection call graph window. On 21.02.2012 4:12, Patrick Spendrin wrote: > https://bugs.kde.org/show_bug.cgi?id=288164 > > > Patrick Spendrin<ps_ml@gmx.de> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ps_ml@gmx.de > > > > > --- Comment #6 from Patrick Spendrin<ps_ml gmx de> 2012-02-21 00:12:21 --- > Can you please provide a simple test case that I can use to confirm this bug > here? >
Of course I meant a file which makes it even possible to select call graph tab - I don't have any example files here and no idea where to get one from.
(In reply to comment #8) > Of course I meant a file which makes it even possible to select call graph > tab - I don't have any example files here and no idea where to get one from. Callgrind files are text files. Just copy the smallest example from the format description from http://valgrind.org/docs/manual/cl-format.html, put it into a file with a text editor and load that.
Ok, a better backtrace here: Application: KCachegrind (kcachegrind), signal: EXCEPTION_ACCESS_VIOLATION QtCore4.dll!QProcess::closeWriteChannel() [q:\qt-4.7.4\src\corelib\io\qprocess.cpp @ 1273] at 0x68c388c1 kcachegrind.exe!CallGraphView::refresh() [s:\branches\kde\4.8\kdesdk\kcachegrind\libviews\callgraphview.cpp @ 2080] at 0xaf5f0f kcachegrind.exe!CallGraphView::doUpdate() [s:\branches\kde\4.8\kdesdk\kcachegrind\libviews\callgraphview.cpp @ 1928] at 0xaf9895 kcachegrind.exe!TraceItemView::triggerUpdate() [s:\branches\kde\4.8\kdesdk\kcachegrind\libviews\traceitemview.cpp @ 309] at 0xae3ccf kcachegrind.exe!TraceItemViewUpdateTimer::timeoutTriggered() [s:\branches\kde\4.8\kdesdk\kcachegrind\libviews\traceitemview.cpp @ 44] at 0xae3cea kcachegrind.exe!TraceItemViewUpdateTimer::qt_metacall() [l:\build\kde\kdesdk-20120127\work\msvc2010-relwithdebinfo-svnhead\kcachegrind\libviews\traceitemview.moc @ 75] at 0xae3d71 QtCore4.dll!QMetaObject::activate() [q:\qt-4.7.4\src\corelib\kernel\qobject.cpp @ 16707566] at 0x68ca1f36 QtCore4.dll!QTimer::timerEvent() [q:\qt-4.7.4\src\corelib\kernel\qtimer.cpp @ 271] at 0x68ca5617 QtCore4.dll!QObject::event() [q:\qt-4.7.4\src\corelib\kernel\qobject.cpp @ 1253] at 0x68c9e9db QtGui4.dll!QApplicationPrivate::notify_helper() [q:\qt-4.7.4\src\gui\kernel\qapplication.cpp @ 4482] at 0x6778eb9d QtGui4.dll!QApplication::notify() [q:\qt-4.7.4\src\gui\kernel\qapplication.cpp @ 4446] at 0x6778e467 kdeui.dll!KApplication::notify() [q:\kdelibs\kdeui\kernel\kapplication.cpp @ 312] at 0x68369270 QtCore4.dll!QCoreApplication::notifyInternal() [q:\qt-4.7.4\src\corelib\kernel\qcoreapplication.cpp @ 800] at 0x68c8d7cd QtCore4.dll!QEventDispatcherWin32Private::sendTimerEvent() [q:\qt-4.7.4\src\corelib\kernel\qeventdispatcher_win.cpp @ 645] at 0x68cb1585 QtCore4.dll!QEventDispatcherWin32::event() [q:\qt-4.7.4\src\corelib\kernel\qeventdispatcher_win.cpp @ 1153] at 0x68cb2da8 QtGui4.dll!QApplicationPrivate::notify_helper() [q:\qt-4.7.4\src\gui\kernel\qapplication.cpp @ 4482] at 0x6778eb9d QtGui4.dll!QApplication::notify() [q:\qt-4.7.4\src\gui\kernel\qapplication.cpp @ 4446] at 0x6778e467 kdeui.dll!KApplication::notify() [q:\kdelibs\kdeui\kernel\kapplication.cpp @ 312] at 0x68369270 QtCore4.dll!QCoreApplication::notifyInternal() [q:\qt-4.7.4\src\corelib\kernel\qcoreapplication.cpp @ 800] at 0x68c8d7cd QtCore4.dll!QCoreApplication::sendEvent() [q:\qt-4.7.4\src\corelib\kernel\qcoreapplication.h @ 215] at 0x68c91386 QtCore4.dll!QCoreApplicationPrivate::sendPostedEvents() [q:\qt-4.7.4\src\corelib\kernel\qcoreapplication.cpp @ 1428] at 0x68c8e2c8 QtCore4.dll!qt_internal_proc() [q:\qt-4.7.4\src\corelib\kernel\qeventdispatcher_win.cpp @ 497] at 0x68cb102f USER32.dll!gapfnScSendMessage() [[unknown] @ -1] at 0x76a362fa USER32.dll!GetThreadDesktop() [[unknown] @ -1] at 0x76a36d3a USER32.dll!CharPrevW() [[unknown] @ -1] at 0x76a377c4 USER32.dll!DispatchMessageW() [[unknown] @ -1] at 0x76a3788a QtCore4.dll!QEventDispatcherWin32::processEvents() [q:\qt-4.7.4\src\corelib\kernel\qeventdispatcher_win.cpp @ 810] at 0x68cb203a QtGui4.dll!QGuiEventDispatcherWin32::processEvents() [q:\qt-4.7.4\src\gui\kernel\qapplication_win.cpp @ 1170] at 0x677eb8bf QtCore4.dll!QEventLoop::exec() [q:\qt-4.7.4\src\corelib\kernel\qeventloop.cpp @ 201] at 0x68c8c4e6 QtCore4.dll!QCoreApplication::exec() [q:\qt-4.7.4\src\corelib\kernel\qcoreapplication.cpp @ 1064] at 0x68c8dc7c kcachegrind.exe!main() [s:\branches\kde\4.8\kdesdk\kcachegrind\kcachegrind\main.cpp @ 91] at 0xaa1b3e kcachegrind.exe!WinMain() [q:\qt-4.7.4\src\winmain\qtmain_win.cpp @ 135] at 0xaa1125 kcachegrind.exe!__tmainCRTStartup() [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 547] at 0xb37604 kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5 ntdll.dll!ZwWaitForMultipleObjects() [[unknown] @ -1] at 0x7755013d kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5 ntdll.dll!NtRemoveIoCompletion() [[unknown] @ -1] at 0x7754f939 kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5 ntdll.dll!ZwWaitForMultipleObjects() [[unknown] @ -1] at 0x7755013d kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5 ntdll.dll!ZwWaitForWorkViaWorkerFactory() [[unknown] @ -1] at 0x77551f26 kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5 ntdll.dll!ZwWaitForWorkViaWorkerFactory() [[unknown] @ -1] at 0x77551f26 kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5 ntdll.dll!ZwDelayExecution() [[unknown] @ -1] at 0x7754fd71 KERNELBASE.dll!Sleep() [[unknown] @ -1] at 0x765a3a8b ole32.dll!CoGetTreatAsClass() [[unknown] @ -1] at 0x7501d98d ole32.dll!CoGetTreatAsClass() [[unknown] @ -1] at 0x7501d87a kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5 ntdll.dll!ZwWaitForMultipleObjects() [[unknown] @ -1] at 0x7755013d kernel32.dll!WaitForMultipleObjectsEx() [[unknown] @ -1] at 0x74d51a2c kernel32.dll!WaitForMultipleObjects() [[unknown] @ -1] at 0x74d54208 QtCore4.dll!QWindowsFileSystemWatcherEngineThread::run() [q:\qt-4.7.4\src\corelib\io\qfilesystemwatcher_win.cpp @ 335] at 0x68c77692 QtCore4.dll!QThreadPrivate::start() [q:\qt-4.7.4\src\corelib\thread\qthread_win.cpp @ 317] at 0x68bb6f88 MSVCR100.dll!endthreadex() [[unknown] @ -1] at 0x691fc556 MSVCR100.dll!endthreadex() [[unknown] @ -1] at 0x691fc600 kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5 ntdll.dll!ZwWaitForWorkViaWorkerFactory() [[unknown] @ -1] at 0x77551f26 kernel32.dll!BaseThreadInitThunk() [[unknown] @ -1] at 0x74d5339a ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ef2 ntdll.dll!RtlInitializeExceptionChain() [[unknown] @ -1] at 0x77569ec5
Created attachment 69336 [details] correctly check if the render process cannot be started Please review this patch, it fixes the crash & displays some more information.
Created attachment 69337 [details] Alternative fix Simpler patch. No need to check if process could be started. If not, anything written to its stdin will be discarded anyway. However, the real problem is that _renderProcess could be set to 0 (in dotError(), on detection that process could not be started), and afterwards used in "_renderProcess->closeWriteChannel()". It should be enough to have a local "renderProcess" variable that can not be set to 0 from the outside.
Can you check my fix? Your patch has the problem that perhaps the process could be started, but another error appears, dotError() is called, and "_renderProcess->closeWriteChannel();" still segfaults. I am reluctant to use "waitForStarted()", as it can block the GUI. But I just see that I have a memory leak, as the QProcess object is not deleted when the process failed to start...
sorry for not coming back to you earlier, but the alternative fix has one problem: instead of stopping right away and showing the broken command, it displays "Layouting stopped. The call graph has 3 nodes and 3 edges." I'd rather have it display the failed command (dot -Tplain iirc) and making me install graphviz.
(In reply to comment #14) > sorry for not coming back to you earlier, but the alternative fix has one > problem: instead of stopping right away and showing the broken command,... > displays "Layouting stopped. The call graph has 3 nodes and 3 edges." There is something wrong. An error (such as FailedToStart) triggers a call to dotError(), which should show the error message about not being able to run dot... Why is the change to dotError() in your patch needed anyway? It always calls showRenderError(), also without your changes. Therefore, I do not understand why your patch shows the correct message.
One additional thing I noticed: for a very short time the error message really pops up, but is replaced by the timeout before being readable at all.
Created attachment 69548 [details] Corrected alternative patch I think a found the problem. Asynchronous behavior simply is tricky. It could be that the renderTimer showing the warning you mentioned is started only after the failedToStart error is detected, thus overwriting the error message. So, better start the renderTimer before trying to start the layouting process. This will make sure that an error stops the renderTimer. Does this help?
Yes, this works better without dot.exe in the path, I just need to find out why it doesn't work if dot.exe is in the path.
Ok, found the reason, please commit & close this bug report.
Fixed in r1285259.