Bug 288164

Summary:	Crash at selection of Call Graph tab
Product:	[Developer tools] kcachegrind	Reporter:	Serge <syanenko>
Component:	general	Assignee:	Josef Weidendorfer <josef.weidendorfer>
Status:	RESOLVED FIXED
Severity:	normal	CC:	kde-windows, ps_ml
Priority:	NOR
Version:	0.6kde
Target Milestone:	---
Platform:	Microsoft Windows
OS:	Microsoft Windows
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	correctly check if the render process cannot be started Alternative fix Corrected alternative patch

Description Serge 2011-12-03 22:34:46 UTC

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

Comment 1 Josef Weidendorfer 2011-12-05 19:11:47 UTC

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?

Comment 2 Serge 2011-12-05 19:33:56 UTC

(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

Comment 3 Josef Weidendorfer 2011-12-05 19:47:03 UTC

(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

Comment 4 Serge 2011-12-05 20:07:21 UTC

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.

Comment 5 Josef Weidendorfer 2011-12-05 23:43:59 UTC

(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.

Comment 6 Patrick Spendrin 2012-02-21 00:12:21 UTC

Can you please provide a simple test case that I can use to confirm this bug here?

Comment 7 Serge 2012-02-21 09:06:29 UTC

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?
>

Comment 8 Patrick Spendrin 2012-03-06 19:08:37 UTC

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.

Comment 9 Josef Weidendorfer 2012-03-06 19:26:40 UTC

(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.

Comment 10 Patrick Spendrin 2012-03-06 21:05:42 UTC

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

Comment 11 Patrick Spendrin 2012-03-06 21:53:20 UTC

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.

Comment 12 Josef Weidendorfer 2012-03-06 22:08:42 UTC

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.

Comment 13 Josef Weidendorfer 2012-03-06 22:16:34 UTC

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...

Comment 14 Patrick Spendrin 2012-03-12 16:03:48 UTC

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.

Comment 15 Josef Weidendorfer 2012-03-12 18:23:44 UTC

(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.

Comment 16 Patrick Spendrin 2012-03-12 18:36:11 UTC

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.

Comment 17 Josef Weidendorfer 2012-03-12 18:46:58 UTC

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?

Comment 18 Patrick Spendrin 2012-03-12 20:03:45 UTC

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.

Comment 19 Patrick Spendrin 2012-03-12 21:49:00 UTC

Ok, found the reason, please commit & close this bug report.

Comment 20 Josef Weidendorfer 2012-03-13 00:03:49 UTC

Fixed in r1285259.