Looks like another victim of libc2.10 and its malloc-check. If you can reproduce this with MALLOC_CHECK_ set to 0 please re-open.

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

Crash reproduced with MALLOC_CHECK_=0.
Although this time it manifests itself as a segfault since malloc-check isn't catching it and aborting, but the trace is essentially the same. I would be inclined to think that anything that gets dug up by the check is a bug anyway, the check just catches invalid memory operations before they escalate into something worse, does it not? I don't think the solution is to disable something that is being strict about correct program operation in an attempt to sweep a bug under the rug (scuse the expression).

Application: KDevelop (kdevelop), signal: Segmentation fault
[KCrash Handler]
#5  0x00007f7ba065e251 in free () from /lib/libc.so.6
#6  0x00007f7b9ed12fd0 in ~KDevVarLengthArray (this=<value optimized out>, __in_chrg=<value optimized out>) at /usr/src/kdevplatform/util/kdevvarlengtharray.h:120
#7  ~AppendedList (this=<value optimized out>, __in_chrg=<value optimized out>) at /usr/src/kdevplatform/language/duchain/appendedlist_static.h:77
#8  ~IdentifierPrivate (this=<value optimized out>, __in_chrg=<value optimized out>) at /usr/src/kdevplatform/language/duchain/identifier.cpp:45
#9  ~Identifier (this=<value optimized out>, __in_chrg=<value optimized out>) at /usr/src/kdevplatform/language/duchain/identifier.cpp:305
#10 0x00007f7b9ecd527b in KDevelop::DUContext::localDeclarations (this=0x56590d0, source=<value optimized out>) at /usr/src/kdevplatform/language/duchain/ducontext.cpp:1087
#11 0x00007f7b7ff57b82 in Cpp::CppDUContext<KDevelop::DUContext>::localDeclarations (this=0x56590d0, source=0x0) at /usr/src/kdevelop/languages/cpp/cppduchain/cppducontext.h:689
#12 0x00007f7b9ed34809 in declarationUnderCursor (c=..., ctx=0x0) at /usr/src/kdevplatform/language/duchain/duchainutils.cpp:253
#13 0x00007f7b9ed34d48 in KDevelop::DUChainUtils::itemUnderCursor (url=<value optimized out>, c=...) at /usr/src/kdevplatform/language/duchain/duchainutils.cpp:279
#14 0x00007f7b841f8dae in ContextBrowserPlugin::findDeclaration (this=<value optimized out>, view=<value optimized out>, position=..., mouseHighlight=<value optimized out>)
    at /usr/src/kdevplatform/plugins/contextbrowser/contextbrowser.cpp:516
#15 0x00007f7b84203e4b in ContextBrowserPlugin::updateBrowserWidgetFor (this=0x306faf0, view=0x33b7cc0) at /usr/src/kdevplatform/plugins/contextbrowser/contextbrowser.cpp:655
#16 0x00007f7b8420448c in ContextBrowserPlugin::updateViews (this=0x306faf0) at /usr/src/kdevplatform/plugins/contextbrowser/contextbrowser.cpp:685
#17 0x00007f7b84204b23 in ContextBrowserPlugin::qt_metacall (this=0x306faf0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fff037acaa0)
    at /usr/src/kdevplatform/build/plugins/contextbrowser/contextbrowser.moc:120
#18 0x00007f7ba2171ff9 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/qt4/libQtCore.so.4
#19 0x00007f7ba216e863 in QObject::event(QEvent*) () from /usr/lib64/qt4/libQtCore.so.4
#20 0x00007f7ba128615c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#21 0x00007f7ba128b9f8 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#22 0x00007f7ba28b42d6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#23 0x00007f7ba21601ee in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/qt4/libQtCore.so.4
#24 0x00007f7ba2187d6d in ?? () from /usr/lib64/qt4/libQtCore.so.4
#25 0x00007f7ba218570d in ?? () from /usr/lib64/qt4/libQtCore.so.4
#26 0x00007f7b9abc0bbf in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#27 0x00007f7b9abc4338 in ?? () from /usr/lib/libglib-2.0.so.0
#28 0x00007f7b9abc4450 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#29 0x00007f7ba2185657 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#30 0x00007f7ba130b38e in ?? () from /usr/lib64/qt4/libQtGui.so.4
#31 0x00007f7ba215eb60 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#32 0x00007f7ba215ed15 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#33 0x00007f7ba2160bdd in QCoreApplication::exec() () from /usr/lib64/qt4/libQtCore.so.4
#34 0x0000000000407e21 in main (argc=<value optimized out>, argv=<value optimized out>) at /usr/src/kdevelop/app/main.cpp:181

(In reply to comment #2)
> Crash reproduced with MALLOC_CHECK_=0.
> Although this time it manifests itself as a segfault since malloc-check isn't
> catching it and aborting, but the trace is essentially the same.

Its not the same, its a lot more helpful as now we know its the same problem as in other cases.

> I would be
> inclined to think that anything that gets dug up by the check is a bug anyway,

From the backtraces I've seen so far it rather seems that the new checks in glibc2.10 are overly strict. There are backtraces reaching deep into Qt code and while they might even point to potential problems, so far I've never seen a crash with such backtrace that was still reproduceable after setting MALLOC_CHECK_.

> the check just catches invalid memory operations before they escalate into
> something worse, does it not? I don't think the solution is to disable
> something that is being strict about correct program operation in an attempt to
> sweep a bug under the rug (scuse the expression).

Its not about sweeping a bug under the rug, as I said this is the first time where malloc_check really was right and its also the first time we might be able to do something about it. All other instances of this reported here have been deep in Qt code, which we won't track here.

> Application: KDevelop (kdevelop), signal: Segmentation fault
> [KCrash Handler]
> #5  0x00007f7ba065e251 in free () from /lib/libc.so.6
> #6  0x00007f7b9ed12fd0 in ~KDevVarLengthArray (this=<value optimized out>,
> __in_chrg=<value optimized out>) at
> /usr/src/kdevplatform/util/kdevvarlengtharray.h:120

Hmm, looking at the code, this is partly a copy of QVarLengthArray, in particular the destructor. I'll ask the author why we have a copy of that code instead of using the Qt version.

Also I can't see anything wrong in the code, if ptr is allocated using qMalloc its also qFree'd. If its just assigned to the tip of the statically-allocated array then its not qFree'd.

We have a copy because the Qt version contained a horrible crash-bug visible in our usecase, and we have some additional convenience methods that give it an API similar to QList.

We could check whether QVarLengthArray in Qt has been fixed meanwhile (valgrind also often reported problems in this class), and if yes, use it as base-class for KDevVarLengthArray instead of copying it over.

This does in fact seem to be rectified with the changes in the latest svn up. Will post if it reoccurs.

OP says this is fixed, so lets close it.