*** This bug has been marked as a duplicate of bug 331521 ***

*** Bug 341099 has been marked as a duplicate of this bug. ***

*** Bug 341344 has been marked as a duplicate of this bug. ***

*** Bug 331521 has been marked as a duplicate of this bug. ***

Please get us a valgrind report, if possible. I'd be really interested to see whats going on here. Alternatively, try to add some debug output to the lambda passed to TopDUContextDynamicData::loadImports. Esp. print out topData->m_importedContextsSize() - maybe the cache got corrupted and that then leads to an extremely large size being read. Which then triggers a OOM crash or similar?

*** Bug 342307 has been marked as a duplicate of this bug. ***

*** Bug 343162 has been marked as a duplicate of this bug. ***

Created attachment 90620 [details]
valgring full log

My system:
Mageia 5 beta 2 with kernel: 3.18.3-server-2.mga5
KDE-4.14.3 based on Qt-4.8.6 with KDevelop-4.7.0 (kdevplatform4-1.7.0)
gcc 4.9.2; valgrind-3.10.0

I was working couple of hours with KDevelop running under valgrind. Unfortunately (because we are looking for crash) KDevelop didn't crash :-/. 
First I need to say that work is very uncomfortable. Lags on every step. Work was really slowed down. I didn't expect so much slowing down. No matter. The mater is that I found in logs interested call (I hope), which one happens during crash. Please find it below:

<code>
==2229== Invalid read of size 4
==2229==    at 0x67F6C66: operator() (topducontextdynamicdata.cpp:509)
==2229==    by 0x67F6C66: loadPartialData<KDevelop::TopDUContextDynamicData::loadImports(uint)::<lambda(const KDevelop::TopDUContextData*)> > (topducontextdynamicdata.cpp:173)
==2229==    by 0x67F6C66: KDevelop::TopDUContextDynamicData::loadImports(unsigned int) (topducontextdynamicdata.cpp:511)
==2229==    by 0x682A5C8: KDevelop::ParsingEnvironmentFile::imports() const (parsingenvironment.cpp:180)
==2229==    by 0x68CF3FE: allImportedFiles(KSharedPtr<KDevelop::ParsingEnvironmentFile>, QSet<KDevelop::IndexedString>&, QSet<KSharedPtr<KDevelop::ParsingEnvironmentFile> >&) (usescollector.cpp:75)
==2229==    by 0x68CF67F: allImportedFiles(KSharedPtr<KDevelop::ParsingEnvironmentFile>, QSet<KDevelop::IndexedString>&, QSet<KSharedPtr<KDevelop::ParsingEnvironmentFile> >&) (usescollector.cpp:83)
==2229==    by 0x68CF67F: allImportedFiles(KSharedPtr<KDevelop::ParsingEnvironmentFile>, QSet<KDevelop::IndexedString>&, QSet<KSharedPtr<KDevelop::ParsingEnvironmentFile> >&) (usescollector.cpp:83)
==2229==    by 0x68D128C: KDevelop::UsesCollector::startCollecting() (usescollector.cpp:270)
==2229==    by 0x68CA296: KDevelop::UsesWidget::UsesWidget(KDevelop::IndexedDeclaration const&, QSharedPointer<KDevelop::UsesWidget::UsesWidgetCollector>) (useswidget.cpp:529)
==2229==    by 0x68BA428: KDevelop::UsesNavigationContext::UsesNavigationContext(KDevelop::IndexedDeclaration, KDevelop::AbstractNavigationContext*) (usesnavigationcontext.cpp:30)
==2229==    by 0x68B758B: KDevelop::AbstractNavigationContext::execute(KDevelop::NavigationAction const&) (abstractnavigationcontext.cpp:182)
==2229==    by 0x18BDB14E: ContextBrowserPlugin::showUsesDelayed(KDevelop::DUChainPointer<KDevelop::Declaration> const&) (contextbrowser.cpp:384)
==2229==    by 0x18BD6A47: ContextBrowserPlugin::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [clone .part.5] (moc_contextbrowser.cpp:107)
==2229==    by 0x5B1E389: QMetaCallEvent::placeMetaCall(QObject*) (qobject.cpp:524)
==2229==  Address 0x29db1590 is 16 bytes after a block of size 136 in arena "client"
</code>

This is the first one. In log there are several similar. 

Additionally I'm pasting HEAP SUMMARY from end of log (there were few during work).
<code>
==2229== HEAP SUMMARY:
==2229==     in use at exit: 57,442,868 bytes in 94,808 blocks
==2229==   total heap usage: 70,594,878 allocs, 70,500,070 frees, 8,282,028,168 bytes allocated
==2229== 
==2229== LEAK SUMMARY:
==2229==    definitely lost: 51,569 bytes in 313 blocks
==2229==    indirectly lost: 326,956 bytes in 6,647 blocks
==2229==      possibly lost: 2,227,830 bytes in 20,935 blocks
==2229==    still reachable: 54,836,513 bytes in 66,913 blocks
==2229==         suppressed: 0 bytes in 0 blocks
==2229== Rerun with --leak-check=full to see details of leaked memory
==2229== 
==2229== For counts of detected and suppressed errors, rerun with: -v
==2229== Use --track-origins=yes to see where uninitialised values come from
==2229== ERROR SUMMARY: 49856 errors from 87 contexts (suppressed: 2 from 1)
</code>

Full log is attached. I've run it without any options (excluding "--log-file"). I hope it will be helpful with fixing this bug. 
Working with KDevelop I face with this, annoying crash, couple of a day - here: https://bugs.kde.org/show_bug.cgi?id=343162 are my reports of crashes. If will be required I can add to this request all missing gdb logs and backtraces. I didn't included them, because they seemed to be very similar to the first one. Till this time I run KDevelop under gdb, so reports were from gdb. Next time I will try to provide valgrind report only if KDevelop crash.
And one more thing. Closing KDevelop in this session it crashed without debug information, so I could not send crash report.

Damn, this looks nasty. Sorry for the trouble, but sadly looking at the code and your reports, I can't see anything "obvious" that I could change. I'll dig in some more. But, as I said before, could you do me the favor (as you seem to be able to reproduce it regularly) of compiling kdevplatform from sources (the 1.7 branch), with slightly modified sources:

In TopDUContextDynamicData::loadImports (language/duchain/topducontextdynamicdata.cpp:505 and below), please add a 

qDebug() << topData->m_importedContextsSize();

above the ret.reserve(...) call inside the lambda passed to loadPartialData. I still wonder whether the reason is a corrupted data cache which leads to large value being assigned to the size, thus leading to overflows and general crashy madness.

This idea comes from this log, which clearly shows that a completely unrelated memory segment is read:

==2229== Thread 1:
==2229== Invalid read of size 4
==2229==    at 0x67FA41A: node_construct (qlist.h:372)
==2229==    by 0x67FA41A: QList<KDevelop::IndexedDUContext>::append(KDevelop::IndexedDUContext const&) (qlist.h:521)
==2229==    by 0x67F6A08: operator<< (qlist.h:334)
==2229==    by 0x67F6A08: operator() (topducontextdynamicdata.cpp:500)
==2229==    by 0x67F6A08: loadPartialData<KDevelop::TopDUContextDynamicData::loadImporters(uint)::<lambda(const KDevelop::TopDUContextData*)> > (topducontextdynamicdata.cpp:173)
==2229==    by 0x67F6A08: KDevelop::TopDUContextDynamicData::loadImporters(unsigned int) (topducontextdynamicdata.cpp:501)
==2229==    by 0x682B2C2: KDevelop::ParsingEnvironmentFile::importers() const (parsingenvironment.cpp:205)
==2229==    by 0x68D4964: void collectImporters<ImportanceChecker>(ImportanceChecker&, KDevelop::ParsingEnvironmentFile*, QSet<KDevelop::ParsingEnvironmentFile*>&, QSet<KDevelop::ParsingEnvironmentFile*>&) (usescollector.cpp:65)
==2229==    by 0x68D49FB: void collectImporters<ImportanceChecker>(ImportanceChecker&, KDevelop::ParsingEnvironmentFile*, QSet<KDevelop::ParsingEnvironmentFile*>&, QSet<KDevelop::ParsingEnvironmentFile*>&) (usescollector.cpp:67)
==2229==    by 0x68D49FB: void collectImporters<ImportanceChecker>(ImportanceChecker&, KDevelop::ParsingEnvironmentFile*, QSet<KDevelop::ParsingEnvironmentFile*>&, QSet<KDevelop::ParsingEnvironmentFile*>&) (usescollector.cpp:67)
==2229==    by 0x68D1EA3: KDevelop::UsesCollector::startCollecting() (usescollector.cpp:220)
==2229==    by 0x68CA296: KDevelop::UsesWidget::UsesWidget(KDevelop::IndexedDeclaration const&, QSharedPointer<KDevelop::UsesWidget::UsesWidgetCollector>) (useswidget.cpp:529)
==2229==    by 0x68BA428: KDevelop::UsesNavigationContext::UsesNavigationContext(KDevelop::IndexedDeclaration, KDevelop::AbstractNavigationContext*) (usesnavigationcontext.cpp:30)
==2229==    by 0x68B758B: KDevelop::AbstractNavigationContext::execute(KDevelop::NavigationAction const&) (abstractnavigationcontext.cpp:182)
==2229==    by 0x18BDB14E: ContextBrowserPlugin::showUsesDelayed(KDevelop::DUChainPointer<KDevelop::Declaration> const&) (contextbrowser.cpp:384)
==2229==    by 0x18BD6A47: ContextBrowserPlugin::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [clone .part.5] (moc_contextbrowser.cpp:107)
==2229==  Address 0x11519644 is 12 bytes inside a block of size 772 free'd
==2229==    at 0x402A939: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2229==    by 0x51D8E11: QRasterPaintEngineState::~QRasterPaintEngineState() (qpaintengine_raster.cpp:628)
==2229==    by 0x515B107: QPainter::restore() (qpainter.cpp:1695)
==2229==    by 0x527F2BD: QTextLine::draw(QPainter*, QPointF const&, QTextLayout::FormatRange const*) const (qtextlayout.cpp:2404)
==2229==    by 0x5282FAB: QTextLayout::draw(QPainter*, QPointF const&, QVector<QTextLayout::FormatRange> const&, QRectF const&) const (qtextlayout.cpp:1192)
==2229==    by 0x17149C17: KateRenderer::paintTextLine(QPainter&, KSharedPtr<KateLineLayout>, int, int, KTextEditor::Cursor const*) (katerenderer.cpp:558)
==2229==    by 0x17198015: KateViewInternal::paintEvent(QPaintEvent*) (kateviewinternal.cpp:3009)
==2229==    by 0x5050A1A: QWidget::event(QEvent*) (qwidget.cpp:8775)
==2229==    by 0x4FF8CE9: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:4565)
==2229==    by 0x4FFF6D2: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:4351)
==2229==    by 0x4B3CD5E: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:311)
==2229==    by 0x5B0CDFB: QCoreApplication::notifyInternal(QObject*, QEvent*) (qcoreapplication.cpp:953)

*** Bug 344036 has been marked as a duplicate of this bug. ***

Created attachment 91218 [details]
backtrace from gdb

Created attachment 91219 [details]
full gdb output from running including requested debug from TopDUContextDynamicData::loadImports.

Hi

Log from running which one you asked, you can find in attachment.

I've used KDevelop in version 4.7.1. Kernel: 3.19.0-desktop-1.mga5 on Mageia 5 beta2 (32bit) system.
I've made suggested change in source code. This session was taking about 10 minutes (starting from kdevelop starts).
BTW. I've got also crash using KDevelop 4.7.1 in Mageia 4.1 (I can prepare similar backtrace report if this can help), but all tests and logs (in this thread) are referring to Mageia5 beta 2 (with latest updates on a day test).
I would like to tell you that I'm using KDE4 (including their built-in applications) in version 4.14.5 and all work very stable only KDevelop crashes. :(. I've tested also KDevelop 4.7.1 in Mageia 5 beta using Virtual Box and I've got the same result - CRASH. I'm not sure if this is only one distribution where KDevelop doesn't work stable, because I didn't test other ones.

Please consider that in this running of kdevelop I didn't start my application, which indirectly could caused the crash (some bug that result was overwriting of memory). Before I've thought like that, but it seems that it's not caused the crash.

I would like to point out that crash happens very often in the aftermath of using function "Find uses". I invoke it and very often KDevelop crashes (sooner or later) if I want to do someting in editor. Ufortunately this is not replicable. No every start KDevelop (with project) and using option "Find uses" and some action in editor provide to crash, but I've noticed that possibility grows very.

Any news?
I'm afraid to use function "Find uses" to avoid CRASH, which happens me (when modifying code) soon after that. :-(

Sorry Piotr, no news :(

I haven't had any easy way to reproduce such a crash yet and thus could not investigate it properly yet. The projects you are working on - are they open source? Do you have a reliable way to trigger this crash? Maybe that could help.

Otherwise, I can only suggest you try the new KF5/Qt5 based KDevelop with its new and shiny kdev-clang plugin. Maybe that works better.

Sorry for the inconvenience!

:-(
My project is Open Source. This is my own project. This is url to repository: git://git.qtcmd.org/qtcmd2.git. Anyone can clone it.
My way to reproduce is now really easy. Sometimes a go I wasn't sure how to reproduce, but from some time I know and happens every time. As I said before. There are loaded couple of cpp files. I use "Find uses" for any of function in middle size of class (dozen of methods). I'm clicking on one of found result. KDevelop moves me to this code. I start change something in code (found function) or add new code (for example I declare new local variable) or rename parameter in this function. I can't say what exactly triggers CRASH :-/. Starting now crash may happen after couple of minutes (2-3 max) or earlier (couple or dozen seconds). If not happen then repeating above actions made it for sure quickly. At least for me. I suppose attached valgrind log and gdb backtrace didn't help too much. I try to reproduce it again with valgring.

About KF5 (5.10) and Plasma (5.3.1)
I was trying work with Plasma 5 and KF5 (using Kubuntu 15.04), but unfortunately my graphics card (integrated: GeForce 7025) is not supports properly by Plasma 5 and I met big high consumption of CPU (~30% == ~80-90% on 1 core from 4) in standby mode (when I don't do anything) - this is default configuration with added CPU load applet.. I'm talking about work with proprietary drivers and setting OpenGL 2.0 (XRender works the same), because work with nouveau is not possible - it made CRASH (entire Linux system) just after Plasma splash finishes loading.
Back to Plasma5 and proprietary drivers. Guilty is plasmashell process (and in some other distributions xorg 1.6). And the reason, as I found out (reading forums), is that my graphics card doesn't support OpenGL ES standard which is used by Plasma 5 and the most likely never be (support). From this reason I didn't report this problem. I can't see now any sense to buy new hardware to be able comfortable work with Plasma 5 :-/. I was trying couple of Linux distribution with Plasma 5 - result the same or worse. I hope that some day Plasma 5 will work with little older graphics card correct. 
Some solution could be use other than Plasma 5 environment. I mean some light environment like LxQt or similar where nouveau and proprietary drivers working fine. And start new unstable (from master branch) KDevelop. When I recently try it (working on Plasma 5 in KaOS distribution) I was using build from 14/04/2015 and then KDevelop crashed also from other reason (I didn't use kdev-clang) and there were some mess with "Configure editor" settings - there were in two places :-/, so I didn't know which one were correct. Of course work with KDevelop in other than Plasma5 environment is only some workaround. I got used to work in KDE and I like it very much. I would rather don't drop it. KDE4 is working perfectly for me with proprietary drivers. I'm not sure that is possible coexisting both libraries (Plasma 5 and KDE4) in one system, probably not. Sorry for little off topic :-/.

I will try with that workaround and try to use kdev-clang plugin. By the way I can see that still are coming the commits to clang handle. I hope it is ready to work and enough stable now. Thanks for hint.

You do not need Plasma 5 to use KDevelop 5. You can continue to use your KDE 4 Plasma just fine. And once I have some time, I hope to look into your project and try to reproduce the bug. Please, if possible tell me:

- what files do you have open in the editor
- what uses did you try to find
- to what use did you jump
- what did you change

Do you mean I can install KF5 libraries in KDE4?
Whether there will be any conflict with KDE4 libraries?  I would not like to break my working KDE4 :-/.

Today I've tried with my workaround (using Kubuntu 15.04). I mean running KDevelop in lxtq environment. In system were installed KF5 libraries and Plasma 5. I've built KDevelop from master, created packages and installed them. The problem what I met was KDevelop didn't see no one plugins. The only one message what was printed was: "kdevplatform.shell: Unable to find a plugin named ' "KDevWelcomePage" '!". Plugins have been installed in "/usr/lib/x86_64-linux-gnu/plugins/kdevplatform/21". I could not understand why has been chosen exactly such directory, especially "21". After some time of digging in Internet I found solution. I've created symlink calling kdevplatform in plugins of qt5 directory. KDevelop started with all plugins. Didn't test how work kdev-clang, because it was late. I will do it tomorrow (actually today :-).

KDevelop starts with two files: 
    src/filelistview.cpp
    src/vfs/subsystemmanager.cpp
I have opened following plugins, maybe it's matter. Just in case.
left side: Documents, Classes, Projects
bottom: "Code Browser", "Problems", "Breakpoints", "Find/Replace in Files"
right side: "Snippets"  (some time a go I had also "Documents", but I don't know why, it disappeared :-(, despite plugin is turned on)

As I said before, it's not easy to catch. I've made couple of attempts. Below you can find scenario where for sure CRASH happen.

Remove KDevelop cache ("kdevduchain")
Run KDevelop
Go to subsystemmanager.cpp
Ctrl+G and put line 201, Enter
Select showProgressDialog (put cursor on it) and invoke "Find uses"* (searching will take a moment, because cache has been removed)
From "Code Browser" view choose "Line: 141" (this moves to header file)
Switch back to subsystemmanager.cpp in editor
From "Code Browser" view choose "Line: 216"
Go to the first line of this function
Put cursor just behind last parameter name of this function (line: "void SubsystemManager::copyFiles(..." ) and put coma (",") if CRASH not happen then write following " int a, QString b". Crash might to happen or not. If not then close KDevelop, select "Save none" on ask about save data.
Start KDevelop again (you will have opened 3 files)
Go to filelistview.cpp (in editor)
Go to line 317 (Ctrl+G), put cursor on "m_subsystemMngr" member and invoke "Find uses".
Crash may happen or not. If not. The go to, for example, line 898 (using "Code Browser")
Go to the first line of this function (this is "FileListView::keyPressed")
Put cursor behind parameter name and write starting with coma (",")
For me in this moment CRASH appeared.
If crash will not happen then one might to repeat actions with other members (closing KDevelop before)

I hope above is clear :-/.

BTW.
One time, crash happened me in such situation:
KDevelop run only with only one file: src/filelistview.cpp
I've selected (put cursor on) random occurrence of m_subsystemMngr and invoked "Find uses"*
KDevelop crashed immediately.


* "Find uses" - this is name from "Configure Shortcuts" (I have a shortcut to it: Ctrl+M). I think that the same option is available in tool tip when the mouse cursor is over the member, here is calling "Show uses".

I hope you manage to meet some crash.

@Piotr: Just a shoot into the dark.

Could you do the following and attach the output? Considering you still have session where you can reproduce the crash.
  du -k -a ~/.cache/kdevduchain | sort -n | head -n 100

OK. In the moment when I got crash handling window from KDE I executed what you asked.

$ du -k -a ~/.cache/kdevduchain | sort -n | head -n 100
0       /home/piotr/.cache/kdevduchain

Because inside "kdevduchain" directory there is session directory so I executed command again like this:
$ du -k -a ~/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5} | sort -n | head -n 100                                                  
0       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/available_top_context_indices
0       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/version_77
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Code Model_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Comment Repository_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Counters
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/crash_counter
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Definition Map_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Environment Information_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Environment Lists_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/file modification repository_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/file modification sets_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Identifier Repository_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Importer Map_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/include path repository_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Instantiation Information Repository_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/macro repository_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/macro sets_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/parsing_environment_data
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Persistent Declaration Table_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Qualified Identifier Repository_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/Recursive Imports_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/String Index_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/string sets_dynamic
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/10
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/100
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1000
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1001
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1002
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1003
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1004
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1007
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1008
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1009
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/101
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1010
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1011                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1012                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1013                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1014                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1016                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1018                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1019                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/102                                                                                                            
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1020                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1021                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1022                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1023                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1024                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1026                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1027                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1028                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1029                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/103                                                                                                            
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1033                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1036                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1038                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1039                                                                                                           
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/104
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1040
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1041
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1043
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1044
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1045
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1046
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1047
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1048
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1049
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/105
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1050
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1051
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1055
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1056
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1057
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1059
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/106
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1061
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1062
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1063
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1065
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1066
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1069
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/107
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1070
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1072
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1073
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1074
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1076
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/108
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1080
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1081
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1082
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1083
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1084
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1087
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1089
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/109
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1090
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1091
4       /home/piotr/.cache/kdevduchain/kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}/topcontexts/1092

I would like to note that sometimes crash is happen quite quickly and sometimes need to do several following actions:
:loop
- invoke find uses (some method or class member)
- jump to found item
- change or add something (not matter is it in body /in parameter, in cpp / h file)
goto loop

In this case KDevelop was working about 3 hours. I didn't invoke "Find uses" till I got your ask.

Okay, thanks. That's a dead-end. 

I assumed one of the files in topducontexts/ had a size of zero. Not the case.

*** Bug 355068 has been marked as a duplicate of this bug. ***

*** Bug 353692 has been marked as a duplicate of this bug. ***

I just tried to reproduce the crash with your steps but I couldn't get it to crash with KDevelop 5 and kdev-clang. I'll now try to repeat the steps with oldcpp and KDevelop 5.

Actually - has _anyone_ ever seen this crash in KDevelop 5? Or is it maybe only occurring in KDevelop 4?

This crash refers to KDevelop 4.7.x. And I reported it like that.
I met it only in 4-series and in the newest stable (4.7.2) it happens much faster than in previous version. I reported it in separate bug report as Bug 353905 (here version is 1.7.1, because there is no 1.7.2).

I also cannot reproduce it with kdev5 and oldcpp.

*** Bug 353905 has been marked as a duplicate of this bug. ***

Sorry Priotr,

my tests today where again without any progress. Next time, I'll try KDevelop 4, but right now I want to fix more stuff in KDevelop 5.

Considering that not much has changed between KDevelop 4 and 5 in the affected code area, I'm pretty sure that the crash could also manifest itself in KDevelop 5. It's really odd that this is not the case. The only idea I have is that maybe it's yet another oldcpp bug.

*** Bug 352773 has been marked as a duplicate of this bug. ***

Hmm. I think you told me that in KDevelop 5 there is pretty new parser based on clang, so I thought this is new code. Never mind. Maybe not all is new.
What do you mean saying "another oldcpp bug"?
Here, in Mageia 5, I have installed "libstdc++6-4.9.2-4.1.mga5" is this "oldcpp"? Or you mean oldcpp plugin in KDevelop?

Back to test.
OK. I tried to reproduce it again using this time test case from Bug 353905 (marked as duplicate) with KDevelop-4.7.2 on Mageia 5 (on real machine, but it happen also in VirtualBox 5).

I will say at the outset that my KDevelop cache is placed on the ram disk, so I have linked "~/.cache/kdevduchain" to /tmp/piotr-kdevduchain. I'm not sure if this is important, but maybe will help.

Going further.
Before running the test I removed kdevduchain cache (of course KDevelop wasn't running in this moment) - it was session directory calling: "kdevelop-{e4d7275a-9f43-4eb0-a9cb-f5cb819a0df5}".
Time for the steps (a bit improved comparing mentioned bug report):

1. Run KDevelop with my project (qtcmd2) and only opened src/filelistview.cpp
2. When cache has been generated. Find (using shortcut Ctrl+Alt+N) following method: slotOpenSelected
3. Find following line: "m_sLastSelectedItemName = currentFileName();" (the way of looking doesn't matter)
    Note, In this function there are two occurrences such assignment and in my test I used second one, which is placed couple of lines below first one.
4. Move cursor on the "currentFileName()" (second occurrence)
5. Invoke "Show uses"

KDevelop doesn't crash, but parser does something through for a while and stops on 25% (see attachment) or 0% (happened when I repeat test). Anyway I was waiting till finished about 10-15 min. and nothing changed. So I started to invoked other "Find uses" on other functions located in slotOpenSelected, for example: "slotBreakCurrentOperation" - no result, "openSelectedItemsWith" - no result, "numberOfSelectedItems" - no result. Code browser still empty. Only I can see that KDevelop uses a lot of CPU:

 PID   USER      PRI  NI  VIRT    RES     SHR     S CPU% MEM%   TIME+     Command
 1076 piotr      20   0   1476M 1076M 77624 S 69.3    6.7         12:58.44  /usr/bin/kdevelop
 1188 piotr      20   0   1476M 1076M 77624 S 16.4    6.7           4:04.99  /usr/bin/kdevelop
 1097 piotr      20   0   1476M 1076M 77624 S 11.6    6.7           3:54.56  /usr/bin/kdevelop
 1182 piotr      20   0   1476M 1076M 77624 R 40.7    6.7           3:53.70  /usr/bin/kdevelop

And still allocates more and more memory. Please take a look at the screen shots. Second one I made several dozen after first one. I have now 16GB ram and swap, so I will wait a while till free memory finished and then probably KDevelop crashed. In a moment of original test I had only 4GB, so it happened a bit faster.
Anyway when I closed KDevelop then I get "KDevelop crash window" - using to send crash report. I didn't attach report, because it told me that I have not enough information for programmers (despite I have installed debug packages). I know that I should to run KDevelop in gdb If I want to get the backtrace from the crash.

I think it should finish ("Find uses" operation) really quickly, because I have now quite strong hardware (Core i7-6700 Skylake + 16GB ram). Before (in a moment of original test) I had AMD Phenom II X4 955 + 4GB and happened the same. OK. Sometime KDevelop crashed faster.

When I was using 4.7.1 version I didn't observe such behavior. KDevelop either worked (all were found) or crashed, but didn't parser stop like this and allocated memory without end.

Because this test based on my project I remind its location: git://git.qtcmd.org/qtcmd2.git
Sorry, my test is not some simply one-file project. I didn't test this with other project.

Created attachment 95908 [details]
"Find uses" hungs with 25%

Created attachment 95909 [details]
Find_uses-memory_usage1

Created attachment 95910 [details]
Find_uses-memory_usage2

I tried to reproduce it (including cache located on ram disk) using KDevelop 4.90.90 (cloned at 30.11.2015, run on Kubuntu 15.10, Plasma 5 session) and here all is working fine. "Find uses" function found all matching occurrences of "currentFileName()" and finished with success.

This is fixed by:

commit 14df9ba1a88e41193bf65f9d87f2849747f664b3
Author: Kevin Funk <kfunk@kde.org>
Date:   Wed Jan 20 09:25:18 2016 +0100

    TopContextDynamicData: Fix bug in loadPartialData
    
    Detected using ASAN
    
    Regression introduced by 49e4b656f0e54bff882f03efe04feedff5994ed1

Backported to 1.7 branch; will be part of 1.7.3.

commit c8fa1a6ba1f2226918597df091060b1c205f1a4f
Author: Kevin Funk <kfunk@kde.org>
Date:   Wed Jan 20 09:25:18 2016 +0100

    TopContextDynamicData: Fix bug in loadPartialData
    
    Detected using ASAN
    
    Regression introduced by 49e4b656f0e54bff882f03efe04feedff5994ed1