How to reproduce:
1. Start Code::Blocks (Win32 svn rev. 7694)
2. Drag and Drop the CodeBlocks.cbp file to the empty Default Workspace
http://forums.codeblocks.org/index.php/topic,13766.msg95051.html#msg95051I cannot confirm both, this is just working fine for me on Windows. I tried several times, re-starting C::B in between. I even tried with a complete C::B workspace, so having ~80 projects, including the core project.
Recently, I have problems loading projects via drag and drop to the workspace. At first it looks like Code::Blocks loads the project just fine (the project is shown in the workspace tree and marked as active project), but then Code::Blocks freezes.
After some research I could find out, that the DoFullParsing routine doesn't exit when a new Parser is created during the "OnProjectActivated" event. It seems that the loop, which handles the parsing of the priority_files does never exit (nativeparser.cpp line ~1400).DoFullParsing() function just prepare a full parsing (the function name "DoFullParsing" it not quite good I think), it add many thread tasks, and real parsing is done in other working threads. So, I think there are some bugs, but those bugs are hard to track. I don't think we have a good way to debug all the parsing threads.
I figured that the Header Fixup plugin is responsible for about 75% of the default.conf data. The project loading worked again after I removed the <HeaderFixup> section in the default.conf. Alternatively the deactivation of the plugin did also work. I will deactivate it for now because I have no use for it anyway...I saw that, to. The plugin is missing a "dirty" flag to only store data that has been changed. For now, it always saves all data the time you press the configuration dialog with "OK".
However, this is transparent to the rest of C::B and won't hurt. ConfigManager in C::B can handle way more configuration data than that. So besides it's not "nice" it is not an issue.
Have you backed up the faulty conf-file ?QuoteHowever, this is transparent to the rest of C::B and won't hurt. ConfigManager in C::B can handle way more configuration data than that. So besides it's not "nice" it is not an issue.
ConfigManager can certainly handle more data, but it seems somehow to be related with the application crash I encountered.
Have you backed up the faulty conf-file ?I've sent it to you but the error doesn't show up every time, so you might need to open and close Code::Blocks and the project several times. BTW: closing the project seems to be as problematic as opening it and it doesn't matter whether the project has been opend using the Recent Projects List or by a drag'n drop.
If yes, is it possible to send it to me via mail ?
Meanwhile I've tested several revisions and found out, that the first open/close errors came up with the changes in Rev. 7419. After that, the behaviour gets somewhat better or worse during the revisions (sometimes closing a project doesn't freeze Code::Blocks but takes significantly longer than usual) but it never got back to a state that was stable.That revision rewrite the locker in many files, I guess there are some dead locks.
Revision: 7419
Author: loaden
Date: 2011-8-26 14:09:39
Message:
* CC: Rewrite thread lock of TokensTree again
-------------------------------
M : /trunk/src/plugins/codecompletion/ccdebuginfo.cpp
M : /trunk/src/plugins/codecompletion/classbrowser.cpp
M : /trunk/src/plugins/codecompletion/classbrowserbuilderthread.cpp
M : /trunk/src/plugins/codecompletion/classbrowserbuilderthread.h
M : /trunk/src/plugins/codecompletion/codecompletion.cpp
M : /trunk/src/plugins/codecompletion/insertclassmethoddlg.cpp
M : /trunk/src/plugins/codecompletion/insertclassmethoddlg.h
M : /trunk/src/plugins/codecompletion/nativeparser.cpp
M : /trunk/src/plugins/codecompletion/nativeparser.h
M : /trunk/src/plugins/codecompletion/parser/parser.cpp
M : /trunk/src/plugins/codecompletion/parser/parser.h
M : /trunk/src/plugins/codecompletion/parser/parserdummy.cpp
M : /trunk/src/plugins/codecompletion/parser/parserthread.cpp
M : /trunk/src/plugins/codecompletion/parser/parserthread.h
M : /trunk/src/plugins/codecompletion/parser/token.h
That revision rewrite the locker in many files, I guess there are some dead locks.Either that, or (in combination) could you check if you have enabled "parse while typing" in the CC settings? If so, turn it off and try again. I experienced some issues with that feature recently - probably we should remove it or at least disable it by default.
Enabled "parse while typing" is always ON in my c::b, sometimes, c::b hangs for a while(1 second maybe) after I enter some characters. Did you have such issue?That revision rewrite the locker in many files, I guess there are some dead locks.Either that, or (in combination) could you check if you have enabled "parse while typing" in the CC settings? If so, turn it off and try again. I experienced some issues with that feature recently - probably we should remove it or at least disable it by default.
The thread Pool can have a function: Pause and Resume. When we pause it, it just finish the currently running thread, and no new thread should be started. When we resume it, it can continue running.Please don't waste time on such a scheme, because it will fail pretty miserably.
Ok, but can we have a better scheme then current "many locker" scheme?The thread Pool can have a function: Pause and Resume. When we pause it, it just finish the currently running thread, and no new thread should be started. When we resume it, it can continue running.Please don't waste time on such a scheme, because it will fail pretty miserably.