Bug 303073 - kcachegrind fails with large PHP cachegrind file
Summary: kcachegrind fails with large PHP cachegrind file
Status: RESOLVED DUPLICATE of bug 232470
Alias: None
Product: kcachegrind
Classification: Developer tools
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Debian stable Linux
: NOR crash
Target Milestone: ---
Assignee: Josef Weidendorfer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-05 19:02 UTC by Larry Crouch
Modified: 2012-07-06 18:07 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Larry Crouch 2012-07-05 19:02:40 UTC
Application: kcachegrind (0.5.1kde)
KDE Platform Version: 4.4.5 (KDE 4.4.5)
Qt Version: 4.6.3
Operating System: Linux 2.6.32-5-686 i686
Distribution: Debian GNU/Linux 6.0.5 (squeeze)

-- Information about the crash:
Running LAMP server with Xdebug. Script takes several minutes to complete which generates a 2.3 GB cachegrind file. Kcachegrind always crashes when around 30-40 percent of the cachegrind file is loaded.

Particulars:
Linux dfw-ws02 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux
Debian Stable
Kcachegrind 0.5.1kde
KDE Development Platform 4.4.5 (KDE 4.4.5)
3 GB Ram


The crash can be reproduced every time.

 -- Backtrace:
Application: KCachegrind (kcachegrind), signal: Segmentation fault
[KCrash Handler]
#6  FixPool::ensureSpace (this=0x880ef80, size=44) at ../../../kcachegrind/libcore/pool.cpp:104
#7  0x0809cc1e in FixPool::allocate (this=0x880ef80, size=44) at ../../../kcachegrind/libcore/pool.cpp:59
#8  0x0809abbe in CachegrindLoader::loadTraceInternal (this=0xbfd3caf0, part=0x8806f98) at ../../../kcachegrind/libcore/cachegrindloader.cpp:1118
#9  0x0809bd9a in CachegrindLoader::loadTrace (this=0x85b38c0, p=0x8806f98) at ../../../kcachegrind/libcore/cachegrindloader.cpp:180
#10 0x0808de60 in TraceData::addPart (this=0x880bf68, dir=..., name=...) at ../../../kcachegrind/libcore/tracedata.cpp:3380
#11 0x08092f51 in TraceData::load (this=0x880bf68, base=...) at ../../../kcachegrind/libcore/tracedata.cpp:3302
#12 0x0806ff91 in TopLevel::loadTrace (this=0x85b1628, file=) at ../../../kcachegrind/kcachegrind/toplevel.cpp:946
#13 0x080704ce in TopLevel::loadTraceDelayed (this=0x85b1628) at ../../../kcachegrind/kcachegrind/toplevel.cpp:1013
#14 0x080716bd in TopLevel::qt_metacall (this=0x85b1628, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfd3cf1c) at ./toplevel.moc:323
#15 0xb6aab7aa in QMetaObject::metacall (object=0x85b1628, cl=4294967224, idx=131, argv=0xbfd3cf1c) at kernel/qmetaobject.cpp:237
#16 0xb6aba1bb in QMetaObject::activate (sender=0x87f8dd8, m=0xb6bb9308, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3295
#17 0xb6ac1a77 in QSingleShotTimer::timeout (this=0x87f8dd8) at .moc/release-shared/qtimer.moc:82
#18 0xb6ac1b8c in QSingleShotTimer::timerEvent (this=0x87f8dd8) at kernel/qtimer.cpp:308
#19 0xb6ab6c54 in QObject::event (this=0x87f8dd8, e=0x0) at kernel/qobject.cpp:1212
#20 0xb5fef5cc in QApplicationPrivate::notify_helper (this=0x851a5d0, receiver=0x87f8dd8, e=0xbfd3d450) at kernel/qapplication.cpp:4302
#21 0xb5ff615e in QApplication::notify (this=0xbfd3d7b8, receiver=0x87f8dd8, e=0xbfd3d450) at kernel/qapplication.cpp:3706
#22 0xb706dbfa in KApplication::notify (this=0xbfd3d7b8, receiver=0x87f8dd8, event=0xbfd3d450) at ../../kdeui/kernel/kapplication.cpp:302
#23 0xb6aa64cb in QCoreApplication::notifyInternal (this=0xbfd3d7b8, receiver=0x87f8dd8, event=0xbfd3d450) at kernel/qcoreapplication.cpp:726
#24 0xb6ad5796 in QCoreApplication::sendEvent (this=0x851d3a4) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#25 QTimerInfoList::activateTimers (this=0x851d3a4) at kernel/qeventdispatcher_unix.cpp:603
#26 0xb6ad2384 in timerSourceDispatch (source=0x851d370) at kernel/qeventdispatcher_glib.cpp:184
#27 0xb5675305 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#28 0xb5678fe8 in ?? () from /lib/libglib-2.0.so.0
#29 0xb56791c8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#30 0xb6ad2075 in QEventDispatcherGlib::processEvents (this=0x8506330, flags=...) at kernel/qeventdispatcher_glib.cpp:412
#31 0xb60aded5 in QGuiEventDispatcherGlib::processEvents (this=0x8506330, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#32 0xb6aa4ae9 in QEventLoop::processEvents (this=0xbfd3d714, flags=) at kernel/qeventloop.cpp:149
#33 0xb6aa4f3a in QEventLoop::exec (this=0xbfd3d714, flags=...) at kernel/qeventloop.cpp:201
#34 0xb6aaa16f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1003
#35 0xb5fef667 in QApplication::exec () at kernel/qapplication.cpp:3581
#36 0x080625fb in main (argc=4, argv=0xbfd3d904) at ../../../kcachegrind/kcachegrind/main.cpp:91

Reported using DrKonqi
Comment 1 Josef Weidendorfer 2012-07-06 09:11:31 UTC
That's the same as bug 232470.
It's an out-of-memory triggered by loading the huge file.

Two work-arounds for the moment:
(1) try to run a 64-bit kcachegrind
(2) in libcore/fixcost.h, set the define for USE_FIXCOST to 0, and recompile.

Even with 64-bit, your machine with 3 GB could probably will start heavy swapping.
So (2) is better, as it will aggregate the profile information while loading, and
memory requirements stay low.

*** This bug has been marked as a duplicate of bug 232470 ***
Comment 2 Larry Crouch 2012-07-06 18:07:58 UTC
On Friday, July 06, 2012 04:11:31 you wrote:
> https://bugs.kde.org/show_bug.cgi?id=303073
> 
> Josef Weidendorfer <josef.weidendorfer@gmx.de> changed:
> 
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
> - Status|UNCONFIRMED                 |RESOLVED
>          Resolution|---                         |DUPLICATE
> 
> --- Comment #1 from Josef Weidendorfer <josef.weidendorfer@gmx.de> ---
> That's the same as bug 232470.
> It's an out-of-memory triggered by loading the huge file.
> 
> Two work-arounds for the moment:
> (1) try to run a 64-bit kcachegrind
> (2) in libcore/fixcost.h, set the define for USE_FIXCOST to 0, and
> recompile.
> 
> Even with 64-bit, your machine with 3 GB could probably will start heavy
> swapping.
> So (2) is better, as it will aggregate the profile information while
> loading, and
> memory requirements stay low.
> 
> *** This bug has been marked as a duplicate of bug 232470 ***


My apologies for the duplicate. My search was not good enough I guess. Thank 
you for the information and work-around.