|Summary:||Crash while changing branch: ProjectModel not threadsafe!|
|Product:||[Applications] kdevelop||Reporter:||Andreas Cord-Landwehr <cordlandwehr>|
|Component:||Build tools: CMake||Assignee:||kdevelop-bugs-null|
|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|
|Latest Commit:||http://commits.kde.org/kdevelop/9d86e6f415d763f83bc183f85f5dd851e80ec95c||Version Fixed In:|
New crash information added by DrKonqi
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
Comment 1 Milian Wolff 2012-02-06 21:20:02 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.
Comment 2 Matthew Woehlke 2012-06-19 23:05:27 UTC
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
Comment 3 Milian Wolff 2012-08-06 14:25:27 UTC
*** Bug 303542 has been marked as a duplicate of this bug. ***
Comment 4 Aleix Pol 2012-08-06 16:51:28 UTC
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...
Comment 5 Ivan Shapovalov 2012-08-07 07:43:33 UTC
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?
Comment 6 Aleix Pol 2012-08-07 10:18:08 UTC
Well... here the tree is reloaded, I think. I'll look into this, but I think it works.
Comment 7 Ivan Shapovalov 2012-08-07 14:50:06 UTC
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.
Comment 8 Aleix Pol 2012-08-07 15:04:14 UTC
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.
Comment 9 Ivan Shapovalov 2012-08-07 15:28:33 UTC
Ah, you're actually right. That's in master.
Comment 10 Aleix Pol 2012-08-21 02:16:43 UTC
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
Comment 11 Milian Wolff 2012-10-04 22:55:59 UTC
*** Bug 307177 has been marked as a duplicate of this bug. ***
Comment 12 Milian Wolff 2012-10-04 22:57:30 UTC
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).
Comment 13 Aleix Pol 2012-10-28 18:31:44 UTC
*** Bug 273418 has been marked as a duplicate of this bug. ***
Comment 14 Aleix Pol 2012-10-28 18:59:02 UTC
*** Bug 286207 has been marked as a duplicate of this bug. ***
Comment 15 Techwolf 2012-12-01 02:43:02 UTC
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
Comment 16 Valentin Rusu 2012-12-12 13:36:01 UTC
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
Comment 17 Milian Wolff 2012-12-22 18:50:22 UTC
*** Bug 312040 has been marked as a duplicate of this bug. ***
Comment 18 Matthew Woehlke 2013-01-01 20:40:50 UTC
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
Comment 19 Milian Wolff 2013-01-13 18:48:55 UTC
*** Bug 284460 has been marked as a duplicate of this bug. ***
Comment 20 Aleix Pol 2013-02-27 18:15:03 UTC
*** Bug 303281 has been marked as a duplicate of this bug. ***
Comment 21 Aleix Pol 2013-02-27 18:42:46 UTC
*** Bug 297119 has been marked as a duplicate of this bug. ***
Comment 22 Aleix Pol 2013-03-18 12:16:03 UTC
*** Bug 316703 has been marked as a duplicate of this bug. ***
Comment 23 Aleix Pol 2013-05-05 10:59:25 UTC
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
Comment 24 Aleix Pol 2013-05-08 13:21:59 UTC
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
Comment 25 Steffen Ohrendorf 2013-06-02 03:10:12 UTC
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?
Comment 26 Aleix Pol 2013-06-10 18:44:09 UTC
At the moment, we should only be deleting items from the GUI thread. Can you run it with valgrind and try to reproduce?
Comment 27 Steffen Ohrendorf 2013-06-12 03:20:48 UTC
It's not a problem of deleting an item, but of calling text() and setText() concurrently.
Comment 28 Steffen Ohrendorf 2013-06-24 01:14:33 UTC
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.
Comment 29 Aleix Pol 2013-07-18 11:37:35 UTC
*** Bug 322513 has been marked as a duplicate of this bug. ***
Comment 30 Aleix Pol 2013-09-10 02:12:47 UTC
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