Code::Blocks Forums
User forums => Help => Topic started by: MortenMacFly on October 20, 2006, 02:39:22 pm
-
Dear all,
I have an issue that C::B freezes if you do the following:
1.) Open a file in an editor
2.) Goto Settings -> Editor.
3.) Toggle the checkbox "Highlight line under cursor..."
4.) Click OK
5.) Have fun with the freeze... ;-)
This does not happen if there is no file open in the editor.
I believe this is related to one of the the find/and replace changes (3101, 3108, 3110...).
Whoever did these - could you please check what might cause this?
With regards, Morten.
-
me too, see there
http://forums.codeblocks.org/index.php?topic=4261.msg33663#msg33663
-
me too, see there
http://forums.codeblocks.org/index.php?topic=4261.msg33663#msg33663
Yes - same for me. This sucks. :? I vote for reverting these changes immediatley.
With regards, Morten.
-
I vote for reverting these changes immediatley.
i can't imagine, how this bug is related to find & replace dialog changes ?
need to find the reason first ...
-
I highly doubt this has anything to do with search replace. Major changes of serach and replace have effect after you issue that command. When starting cb and going to settings, you not near that place (only nearly related change is the removal of setting of searches in the settings dialog))
-
Guys, don't search. It's a race condition in the codecompletion plugin and has to do with the recent wxFNB changes. It's now getting more events than before and I, obviously, have missed something.
I 'll try to fix it this evening.
-
and also these might be related :
http://forums.codeblocks.org/index.php?topic=4257.msg33683#msg33683
http://forums.codeblocks.org/index.php?topic=4261.msg33682#msg33682
-
Guys, don't search. It's a race condition in the codecompletion plugin and has to do with the recent wxFNB changes. It's now getting more events than before and I, obviously, have missed something.
I 'll try to fix it this evening.
You may be right. However I'd like to mention:
1) the wxFNB was updated in svn3090
2) the bug does *not* occur in svn 3094
3) the bug *does* occur in 3103
4) the bug occurs with *only* CC, compiler,debugger plugins loaded
5) the bug only occurs when dismissing the Setting dlg with Ok, not Cancel
So the bug might/must have happened within:
(http://img217.imageshack.us/img217/21/graphic10202006104140amjk4.png)
-
it has been "pointing to this earlier this week" : rev 3100.
Could you try to build with that patch reverted ??
If no-one has done it before i can try, I will try this evening (I hope)
-
2) the bug does *not* occur in svn 3094
3) the bug *does* occur in 3103
So the bug might/must have happened within:
That's what I had in mind, too... and made me believe. Maybe I was wrong.
With regards, Morten.
-
it has been "pointing to this earlier this week" : rev 3100.
Could you try to build with that patch reverted ??
If no-one has done it before i can try, I will try this evening (I hope)
good guess !!!
fixed (reverted rev 3100) now in svn rev 3114
-
So the patch that fixes those random crashes causes crashes...
I just tried Morten's steps to make it crash and it didn't (rev 3111). Also tried tiwag's steps and nothing. Maybe a difference is that I don't use Nightly Builds, I compile it, but why then? HT?
Oh, BTW, I have all plugins enabled.
[edit]
I finally saw it. You have to open a project and then open a file. If I open just a file nothing happens.
[/edit]
-
Re: svn 3114. I concur that the crash/loop is gone.
However, it sure is taking some time for that Settings dlg window to disappear when any options are changed (eg, syntax hilighting).
3-5 seconds on a 1.8mhz Xp Dell 9300.
-
If the 3100 patch works for *nix, why not just put a __wxGTK__ guard around it?
-
If the 3100 patch works for *nix, why not just put a __wxGTK__ guard around it?
Agreed. Those crashes in linux make it very difficult to use.
-
fixed (reverted rev 3100) now in svn rev 3114
You are my "man of the day". That did it! This was definitely worth an update to r3114. Tanks! :-)
With regards, Morten
-
I just want to clear something up, we have removed the patch that increased Linux stability in favor or windows stability? Or have you just made it for __WXGTK__?
-
I think it was removed entirely
-
reapplied it, but only for __wxGTK__, hopefully one day we will fully understand the problem ;-)
-
My guess is the Code Completion plugin access wxWidgets things (building the symbol browser tree for example) in its worker threads and since wxWidgets makes no thread safe guarantees this kind of stuff will happen.
I don't know how the Code Completion works but due to the numbers of thread related errors we are encountering it looks like not enough time was spent during its design phase to carefully define where it interfaces with the rest of CB and then provide thread safe mechanisms of communications.