| Summary: | Crash while changing branch: ProjectModel not threadsafe! | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Andreas Cord-Landwehr <cordlandwehr> |
| Component: | Build tools: CMake | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | aleixpol, b.brachaczek, bugs.kde.org, glad08, intelfx, joris.guisson, jtamate, mwoehlke.floss, peter.aberline, prcoder, sean.lindskog, steffen.ohrendorf, tim, valir, vinesworth, zohn.joidberg |
| Priority: | VHI | ||
| Version: | unspecified | ||
| Target Milestone: | 4.2.3 | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kdevelop/9d86e6f415d763f83bc183f85f5dd851e80ec95c | Version Fixed In: | |
| Attachments: |
New crash information added by DrKonqi
attempt New crash information added by DrKonqi New crash information added by DrKonqi New crash information added by DrKonqi |
||
|
Description
Andreas Cord-Landwehr
2012-02-03 09:14:52 UTC
Jup, pretty clear due to using the thread-*un*-safe Project API from the background in the cmake manager... Aleix, you should never work on project items that are added to the model in a background thread... So for the initial import you could parse the stuff in the background thread and only add the item to the project model afterwards (I think you do that already). Further actions like manual reloading or handling KDirWatcher signals should be handled in the main thread. Or, alternatively, remove the parent item from the model and add it again after you finished processing. I don't like both approaches btw. Rather I think should be handling asynchronously instead of multithreaded. Queue (via signals) the folders that need to be imported and handle them all in the main thread. You could - if that is really that slow, parse the CMakeFiles in a background thread but once you interpret them to alter the ProjectModel, you have to do it in the mainthread. Created attachment 71968 [details]
New crash information added by DrKonqi
kdevelop (4.3.1) on KDE Platform 4.8.3 (4.8.3) using Qt 4.8.2
Seeing almost certainly the same problem here... backtrace is very similar, and likewise happened when I switched between my project's 'master' and 'next' git branches.
-- Backtrace (Reduced):
#6 0x00000030fea35965 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7 0x00000030fea37118 in __GI_abort () at abort.c:91
[...]
#9 0x00000030fea7c80e in malloc_printerr (ptr=0x7fd608671290, str=0x30feb78bf8 "double free or corruption (fasttop)", action=3) at malloc.c:5027
#10 _int_free (av=0x7fd608000020, p=0x7fd608671280, have_lock=0) at malloc.c:3948
#11 0x00000038988c4ee8 in QString::free (d=0x7fd608671290) at tools/qstring.cpp:1235
*** Bug 303542 has been marked as a duplicate of this bug. *** Created attachment 72990 [details]
attempt
Can somebody test it and tell me if this patch solves the crash?
I can't reproduce it by changing kdelibs from 4.2 to 4.9 back and forth, but you know, it never crashes to me but then it explodes on others...
With given patch KDevelop doesn't crash anymore, but project reparse isn't also triggered when you edit CMake files/invoke configure... Is this intended? Well... here the tree is reloaded, I think. I'll look into this, but I think it works. At least the patch makes KDevelop to call configure job before each other job (build, clean, install) even though nothing has been changed... So it should be wrong somewhere. Well that's maybe because of some changes in kdevelop master, it's definitely not something in the patch. If you have problems with that please open a bug report about it and I'll haunt it later. Ah, you're actually right. That's in master. Git commit 2ed699509495bf84a153e8dab625c4620a0437ae by Aleix Pol. Committed on 21/08/2012 at 04:02. Pushed by apol into branch '4.4'. Fix threading problem in the CMakeManager Not only delete the model items from the UI thread but also remove them from the model. M +17 -11 projectmanagers/cmake/cmakemanager.cpp http://commits.kde.org/kdevelop/2ed699509495bf84a153e8dab625c4620a0437ae *** Bug 307177 has been marked as a duplicate of this bug. *** Reopening, this is still broken as-is. Adding stuff to the model is also thread-unsafe and still done as far as I can see (e.g. in CMakeManager::parse). *** Bug 273418 has been marked as a duplicate of this bug. *** *** Bug 286207 has been marked as a duplicate of this bug. *** Created attachment 75558 [details]
New crash information added by DrKonqi
kdevelop (4.4.1) on KDE Platform 4.9.3 using Qt 4.8.3
In a seperate console, I did a hg pull. That is it. I did have some files open on the project, but no un-saved edits.
-- Backtrace (Reduced):
#9 0x00007fe0a7fa90f5 in malloc_printerr (action=3, str=0x7fe0a8098d20 "double free or corruption (fasttop)", ptr=<optimized out>) at malloc.c:4949
#10 0x00007fe0a939eb10 in QString::free (d=0x7fdfe0538860) at tools/qstring.cpp:1235
#11 0x00007fe0a5c30077 in KDevelop::ProjectBaseItem::lessThan (this=<optimized out>, item=<optimized out>) at /var/tmp/portage/dev-util/kdevplatform-1.4.1/work/kdevplatform-1.4.1/project/projectmodel.cpp:378
#12 0x00007fe0a8d8dbf0 in QSortFilterProxyModelPrivate::proxy_intervals_for_source_items_to_add (this=0x86de4d0, proxy_to_source=..., source_items=..., source_parent=..., orient=<optimized out>) at itemviews/qsortfilterproxymodel.cpp:614
#13 0x00007fe0a8d8dfc3 in QSortFilterProxyModelPrivate::insert_source_items (this=<optimized out>, source_to_proxy=..., proxy_to_source=..., source_items=..., source_parent=..., orient=<optimized out>, emit_signal=false) at itemviews/qsortfilterproxymodel.cpp:673
Created attachment 75799 [details]
New crash information added by DrKonqi
kdevelop (4.4.60) on KDE Platform 4.9.80 using Qt 4.8.4
- What I was doing when the application crashed:
I just updated kdelibs-frameworks sources from an external terminal, with them loaded in KDevelop.
-- Backtrace (Reduced):
#10 0x00007f4e4d730168 in QString::free(QString::Data*) () from /usr/lib/libQtCore.so.4
#11 0x00007f4e49f629ca in ~QString (this=<optimized out>, __in_chrg=<optimized out>) at /usr/include/QtCore/qstring.h:880
#12 lessThan (item=0x7f4d0c047e50, this=0x7f4d0d300450) at /home/kde/src/extragear/kdevelop/kdevplatform/project/projectmodel.cpp:394
#13 KDevelop::ProjectBaseItem::lessThan (this=0x7f4d0d300450, item=0x7f4d0c047e50) at /home/kde/src/extragear/kdevelop/kdevplatform/project/projectmodel.cpp:380
[...]
#17 0x00007f4e4d7f806e in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4
*** Bug 312040 has been marked as a duplicate of this bug. *** Created attachment 76129 [details]
New crash information added by DrKonqi
kdevelop (4.4.1) on KDE Platform 4.9.4 using Qt 4.8.4
- What I was doing when the application crashed:
Was adding a new add_subdirectory to a CMakeLists.txt, when KDevelop went piff. Suspect I've seen the same crash at least one other time also, again while editing a CMakeLists.txt.
-- Backtrace (Reduced):
#6 0x00000039a5835935 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7 0x00000039a58370e8 in __GI_abort () at abort.c:91
[...]
#9 0x00000039a587c00e in malloc_printerr (ptr=0x7f4784939b50, str=0x39a5978958 "double free or corruption (fasttop)", action=3) at malloc.c:5027
#10 _int_free (av=0x7f4784000020, p=0x7f4784939b40, have_lock=0) at malloc.c:3948
#11 0x000000345e4c5298 in QString::free (d=0x7f4784939b50) at tools/qstring.cpp:1235
*** Bug 284460 has been marked as a duplicate of this bug. *** *** Bug 303281 has been marked as a duplicate of this bug. *** *** Bug 297119 has been marked as a duplicate of this bug. *** *** Bug 316703 has been marked as a duplicate of this bug. *** Git commit 45cdc3badce74c28cf9bcd4168dd2c1f186dd0f3 by Aleix Pol. Committed on 05/05/2013 at 12:59. Pushed by apol into branch 'master'. Don't store a ProjectBaseItem in the MakeJob Use a QPersistantModelIndex instead and fetch the item only when it's needed. This way we can make sure that we don't crash if the item was deleted during the job's life. This is a bug fix, but I'm only committing to master for the moment. Related: bug 319335 M +0 -1 projectbuilders/makebuilder/makebuilder.cpp M +32 -25 projectbuilders/makebuilder/makejob.cpp M +1 -2 projectbuilders/makebuilder/makejob.h http://commits.kde.org/kdevelop/45cdc3badce74c28cf9bcd4168dd2c1f186dd0f3 Git commit 6f654f7d0e9e85b542d5f19afb1dd552e1891edb by Aleix Pol. Committed on 05/05/2013 at 12:59. Pushed by apol into branch '4.5'. Don't store a ProjectBaseItem in the MakeJob Use a QPersistantModelIndex instead and fetch the item only when it's needed. This way we can make sure that we don't crash if the item was deleted during the job's life. This is a bug fix, but I'm only committing to master for the moment. Related: bug 319335 Conflicts: projectbuilders/makebuilder/makejob.cpp projectbuilders/makebuilder/makejob.h M +0 -1 projectbuilders/makebuilder/makebuilder.cpp M +32 -26 projectbuilders/makebuilder/makejob.cpp M +1 -3 projectbuilders/makebuilder/makejob.h http://commits.kde.org/kdevelop/6f654f7d0e9e85b542d5f19afb1dd552e1891edb This seems to be a race condition between ProjectBaseItem::setText() and text(), resulting in QString returning a free'd string. I tried myself on adding a mutex to the item, but only ran into deadlocks. I'm interested in fixing this, but the question is, as I am not much into the KDevelop code base, what should be made thread-save: the items, the model or both? At the moment, we should only be deleting items from the GUI thread. Can you run it with valgrind and try to reproduce? It's not a problem of deleting an item, but of calling text() and setText() concurrently. Although I ran KDevelop a few times with valgrind, I was not able to reproduce the problem and did not see any warnings about the code dealing with the project model. *** Bug 322513 has been marked as a duplicate of this bug. *** Git commit 9d86e6f415d763f83bc183f85f5dd851e80ec95c by Aleix Pol. Committed on 10/09/2013 at 02:07. Pushed by apol into branch 'master'. Merge branch 'cmakesplit' With this change, I'm making it so the project will be parsed from a separate thread and will pass the data to another thread that will do the tree creation. http://commits.kde.org/kdevelop/9d86e6f415d763f83bc183f85f5dd851e80ec95c |