Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: Martin K. on November 20, 2012, 10:00:21 am
-
Hi,
On Windows7 64Bit, self compiled rev8583 wxwidgets 2.8.12
I have currently no debug version of codeblocks available, and there ist no crash report.
try the following:
Create a new project, console application, finish the configuration dialogs, open main.cpp an enter on an empty line "class thr"
rev8500 runs fine.
Martin
-
Is the Codecompletion-plugin enabled ?
If yes, is "Update parser when typing" enabled ?
Try to disable first the second (if enabled) and then the whole plugin, to see if it still crashes.
-
Hi,
its rev 8581 and not 8583.
Codecompletion is enabled.
It still crashes when i disable only "Update parser when typing"
It does not crash when i disable codecompletion.
Martin
-
I'm not able to make it crash here on XP.
Did you do a full rebuild ?
To be sure remove devel output and .objs.
And make sure no *.gch file is remaining in src/include from (much) older builds.
-
its rev 8581 and not 8583.
Can you please...
- revert to r8580
- remove all object files related to codecompletion (in .objs\plugins\codecompletion\)
- remove the codecompletion DLL
- re-build CC, using the project file in [C::B SVN]\src\plugins\codecompletion\codecompletion.cbp
- try again with the same example?
-
I'm not able to make it crash here on XP.
Me too.
-
its rev 8581 and not 8583.
Can you please...
- revert to r8580
- remove all object files related to codecompletion (in .objs\plugins\codecompletion\)
- remove the codecompletion DLL
- re-build CC, using the project file in [C::B SVN]\src\plugins\codecompletion\codecompletion.cbp
- try again with the same example?
i will try it this evening.
Martin
-
I'm not able to make it crash here on XP.
Me too.
I am able. Just create a console application, then outside the main{} function (a few lines after the closing bracket), start typing:
int main
-> crashes at the time I try to write the "n" if "main".
...but is seems not related to the CC changes after r8580. I'll try with a nightly to see if its my own C::B that causes this.
Also, its not a hard cash, but I get the dialog:
An unhandled exception occurred. Press "Abort" to terminate the program,
"Retry" to exit the program normally and "Ignore" to try to continue.
If I hit "Cancel", I see:
Unknown exception was raised. The application will terminate immediately...
@Martin K.: Can you confirm this?
-
Now it "works" here also.
It seems to happen whenever the cc-tooltip should be shown, Ctrl+Space is enough to make it crash.
-
I'm not able to make it crash here on XP.
Me too.
I am able. Just create a console application, then outside the main{} function (a few lines after the closing bracket), start typing:
int main
-> crashes at the time I try to write the "n" if "main".
...but is seems not related to the CC changes after r8580. I'll try with a nightly to see if its my own C::B that causes this.
Also, its not a hard cash, but I get the dialog:
An unhandled exception occurred. Press "Abort" to terminate the program,
"Retry" to exit the program normally and "Ignore" to try to continue.
If I hit "Cancel", I see:
Unknown exception was raised. The application will terminate immediately...
@Martin K.: Can you confirm this?
I have a windows 7 64 bit system and it tries to find a solution for this problem... but yes, i can confirm this. And as i mentioned before: rev8500 is OK. I have no version between them on this machine.
Martin
-
I found the reason... gimme some more time to test...
-
I found the reason... gimme some more time to test...
Fixed in trunk. Please try and report back. Thank you!
-
Fix confirmed !
Maybe we should remove PARSER_IMG_NONE, because it seems to be useless and potential dangerous.
Or at least comment it out, until we do something useful with it, like binding it to a blank image.
-
Maybe we should remove PARSER_IMG_NONE, because it seems to be useless and potential dangerous.
That wasn't the crash issue, btw. (but feel free to blame me for the crash anyways... :-[). And this image works properly - it also indicates paring failures, i.e. if a visibility could not be obtained. I think it doesn't harm.
-
I found the reason... gimme some more time to test...
Fixed in trunk. Please try and report back. Thank you!
seems to be OK for me.
Martin
-
Maybe we should remove PARSER_IMG_NONE, because it seems to be useless and potential dangerous.
That wasn't the crash issue, btw. (but feel free to blame me for the crash anyways... :-[). And this image works properly - it also indicates paring failures, i.e. if a visibility could not be obtained. I think it doesn't harm.
For me it always crashed, when PARSER_IMG_NONE (aka -2) was returned.
It finally crashed in void ListBoxImpl::RegisterImage(int type, const char *xpm_data) .
-
another one,
rev 8584, clean compile, windows XP, TDM-GCC 4.6.1, GDB 7.4
Start codeblocks, open a project and close Codeblocks before the build button comes active.
Crashes in NativeParser::AdcompilerDirs, plugins\codecompletion\nativeparser.cpp line 2026.
The debugging codeblocks crashes in debugger_gdbmi, debugger_gdb does the job.
secondly i have seen that the time from project load to codeblocks becomes "compile ready" (the build button comes active) becomes longer and longer in the last revisions.
I can not try much revisions to see when it comes into codeblocks. It tooks 1 and a half hour to compile codeblocks with tdm-gcc 4.6.1 (and 4.7.1) on my 4 Core 4GB Windows XP VMWare machine. Maybe i should try an older version of gcc sometime. As far as i remember the 4.4 was much faster (3-5 times) on this machine. That was the reason i asked for MSVC support. But codeblocks doesn't compile, there are some templates that MSVC2010 doesn't understand. (The L"abc" L"xyz" thing worked) but this is another story...
Martin
-
4 core ==> build in parallel ==> you will go down to lest then 15 minutes I think
-
4 core ==> build in parallel ==> you will go down to lest then 15 minutes I think
thats in parallel with 3 cores :-) The host machine has 8 cores with 8 GB Ram.
Martin
-
Start codeblocks, open a project and close Codeblocks before the build button comes active.
Crashes in NativeParser::AdcompilerDirs, plugins\codecompletion\nativeparser.cpp line 2026.
The debugging codeblocks crashes in debugger_gdbmi, debugger_gdb does the job.
Well I cannot reproduce this, but can you try trunk again? I changed a possible crash candidate in this line (although I wonder if that could really crash... timing?!).
-
Start codeblocks, open a project and close Codeblocks before the build button comes active.
Crashes in NativeParser::AdcompilerDirs, plugins\codecompletion\nativeparser.cpp line 2026.
The debugging codeblocks crashes in debugger_gdbmi, debugger_gdb does the job.
Well I cannot reproduce this, but can you try trunk again? I changed a possible crash candidate in this line (although I wonder if that could really crash... timing?!).
The bug still exists at rev8587.
-
Is it possible to use a debugger and provide a callstack of the crash?
-
The bug still exists at rev8587.
Is it possible to use a debugger and provide a callstack of the crash?
True - or at least again at what line exactly it crashes now... I still cannot reproduce.