Created attachment 63699 [details]
assert on null item importing

Can you please try this patch for kdevplatform and tell me if it crashes differently with this?

Created attachment 63703 [details]
New crash information added by DrKonqi

kdevelop (4.2.60) on KDE Platform 4.7.1 (4.7.1) using Qt 4.7.4

- What I was doing when the application crashed:
Opening a cmake-based project. I hope this trace (with the patch applied) helps.

-- Backtrace (Reduced):
#7  0x00007f4a76cbdd26 in KDevelop::ProjectBaseItem::url (this=0x0) at /var/tmp/portage/dev-util/kdevplatform-9999/work/kdevplatform-9999/project/projectmodel.cpp:425
#8  0x00007f4a4ade2ac0 in CMakeManager::parse (this=<value optimized out>, item=<value optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/projectmanagers/cmake/cmakemanager.cpp:671
#9  0x00007f4a76cc4dfa in KDevelop::ImportProjectJobPrivate::import (this=0x490f220, folder=0x7f4a792c3e01) at /var/tmp/portage/dev-util/kdevplatform-9999/work/kdevplatform-9999/project/importprojectjob.cpp:53
#10 0x00007f4a76cc4c74 in QtConcurrent::RunFunctionTask<void>::run (this=0x20a9540) at /usr/include/qt4/QtCore/qtconcurrentrunbase.h:120
[...]

I've did a little bisecting on both kdevplatform and kdevelop.

First I've bisected kdevplatform from 4ab36b4524ea2075fde54f50da94f8fc4c604520 (known good from earlier compile/usage) to 612aedb2e5ca72ea38eaaedcf9208898a032b05f (HEAD of master). Turned out kdevelop needed to be downgraded for this bisect operation so I've used kdevelop 99f57d0bff97571ad25f6a6ab6b02c9ed028ec8f as known good.

kdevplatform did not introduce this bug as kdevelop 99f57d0bff97571ad25f6a6ab6b02c9ed028ec8f works with all commits including HEAD.

Then I've bisected kdevelop from 99f57d0bff97571ad25f6a6ab6b02c9ed028ec8f (known good from above) to 7e781636ea0cde3600e36d907d9c2422b78b2239 (HEAD of master).
git bisect returned this result:
c369136bd76bb2bc4bc876558c78522fdc90a395 is the first bad commit
commit c369136bd76bb2bc4bc876558c78522fdc90a395
Author: Aleix Pol <aleixpol@kde.org>
Date:   Mon Sep 12 04:39:18 2011 +0200

    Export the cmakemodelitems in the cmake library.

:040000 040000 fd2c175c389c25d4cdada54478ff2eec39d01218 38c99f0f63c9f7b99ce87019942d62024dcec128 M	projectmanagers

I've verified again using kdevelop 264948cfa980a050972de6575f5ad2223449dad3 (commit immediately preceding c369136bd76bb2bc4bc876558c78522fdc90a395) and the bug did not occur.

I hope this helps :)

Git commit 38c8eda64333c091e868dbc69a11207636227e52 by Aleix Pol.
Committed on 19/09/2011 at 12:14.
Pushed by apol into branch 'master'.

Get the URL from the item instead of from a dynamic_cast'ed item, just in case.

I'm hoping this will fix the problem in bug 282118, although I'm not sure why it's
being shown now.

BUG: 282118

M  +1    -1    projectmanagers/cmake/cmakemanager.cpp

http://commits.kde.org/kdevelop/38c8eda64333c091e868dbc69a11207636227e52

Created attachment 63778 [details]
New crash information added by DrKonqi

kdevelop (4.2.60) on KDE Platform 4.7.1 (4.7.1) using Qt 4.7.4

Seems the crash has just been postponed now as it now happens just a little bit later but still on loading cmake-based projects.

-- Backtrace (Reduced):
#7  0x00007fee9ec6c9a7 in KDevelop::ProjectBaseItem::rowCount (this=0x0) at /var/tmp/portage/dev-util/kdevplatform-9999/work/kdevplatform-9999/project/projectmodel.cpp:261
#8  0x00007fee9ec6d794 in KDevelop::ProjectBaseItem::folderList (this=0x0) at /var/tmp/portage/dev-util/kdevplatform-9999/work/kdevplatform-9999/project/projectmodel.cpp:495
#9  0x00007fee7ea8e83a in CMakeFolderItem::cleanupBuildFolders (this=0x0, subs=<value optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/projectmanagers/cmake/cmakemodelitems.cpp:104
#10 0x00007fee75a08fc5 in CMakeManager::parse (this=<value optimized out>, item=<value optimized out>) at /var/tmp/portage/dev-util/kdevelop-9999/work/kdevelop-9999/projectmanagers/cmake/cmakemanager.cpp:856
#11 0x00007fee9ec74d92 in KDevelop::ImportProjectJobPrivate::import (this=0x18d44c0, folder=0x3) at /var/tmp/portage/dev-util/kdevplatform-9999/work/kdevplatform-9999/project/importprojectjob.cpp:53

Judging by the commit that fixed it, the bug trackers were quick to judge its resolution as FIXED. The code below follows the main structure of CMakeManager::parse and demonstrates how a crash is certain if folder==NULL:

    CMakeFolderItem* folder = dynamic_cast<CMakeFolderItem*>( item );
    // ...
    if(folder && QFile::exists(cmakeListsPath.toLocalFile()))
    {
    // ...
    } else {
        folder->cleanupBuildFolders(QList<Subdirectory>());
        folder->cleanupTargets(QList<CMakeTarget>());
    }
    reloadFiles(folder);

From my short investigation I deduced the following:

- reloadFiles can be called on the in-parameter item
- the whole if-else can be moved above to protect the else branch if folder==NULL as well
- there are other functions in CMakeManager that attempt to use a folder dynamic_casted from a ProjectBaseItem without checking for NULL (CMakeManager::includeDirectories and CMakeManager::defines. For completeness, CMakeManager::defines is so certain the item will dynamic_cast to a CMakeFolderItem it doesn't even bother to check if the item got past the top item)

With these fixed I can only get the root folder to be parsed as a CMakeFolderItem, and all subfolders get parsed as normal folders (even though they contain a CMakeFiles.txt)

As a result, I believe a quick hacky fix should make sure ProjectBaseItems are always CMakeFolderItem objects.

I have been able to reproduce this on 2 out of 3 computers, one with 4 cores and another with 8 cores. The only computer where this works has 2 cores.

The last commit that I have tried and works on all computers is e9885bbf833429e2fc2b0206ff5cee6370c6287b.

I'm marking as UNCONFIRMED since I don't have the time to look through it right now. Feel free to provide a patch or I'll look into it when I can.

Thanks for taking your time!

The deduction that commit c369136bd76bb2bc4bc876558c78522fdc90a395 introduces this sounds wrong, if that commit makes a difference it would hint at a binary incompatibility i.e. the build and installation directories haven't been deleted during the bisecting. The only thing that changed in that commit is moving classes from one shared lib to another which is a bic change.

I don't understand the code thats been pointed out enough though to see where a ProjectFolderItem could be incorrectly cast into a CMakeModelItem and be added to the folderList. But the code between line 729 and 742 should be inspected I think.

I have done additional tracking on what other differences are between the working and the computers where kdevelop fails. From my perspective the crash appears from a compiler bug. Here are the facts:

- the 2-core working computer is gentoo amd64 (stable) with gcc 4.5.3
- the 8-core failing is gentoo amd64 (stable) with gcc 4.4.5
- the 4-core failing is ubuntu amd64 (lts) with gcc 4.4.3

I have switched to gcc-4.5.3 on the 8-core and kdevelop no longer crashes at startup.

Another interesting fact was while debugging the code mentioned above on the ubuntu 8-core was that before the dynamic_cast, the item variable was holding the valid pointer used when the import job was created. After stepping over the dynamic_cast, folder equaled NULL and GDB said on item that "value optimized out" (which, from my experience, is a red flag about misfires during build)

I think this is worth mentioning, and I am quite curious if anyone else can reproduce this behavior.

(In reply to comment #9)
> Another interesting fact was while debugging the code mentioned above on the
> ubuntu 8-core was that before the dynamic_cast, the item variable was holding
> the valid pointer used when the import job was created. After stepping over the
> dynamic_cast, folder equaled NULL and GDB said on item that "value optimized
> out" (which, from my experience, is a red flag about misfires during build)
> 

Let me rephrase that, since the way I've written before sucks.

I was debugging on the ubuntu 4-core computer. Before executing the dynamic_cast, gdb showed the proper value for the pointer in variable item. After stepping the instruction, item was "optimized out", which raised the question about a deeper issue.

I think this was fixed, or at least I don't know of any reproductions of the problem.

Please reopen if that's not the case.