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.
Quote from: Martin K. on November 20, 2012, 10:41:46 AM
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?
Quote from: MortenMacFly on November 20, 2012, 11:59:10 AM
Quote from: Martin K. on November 20, 2012, 10:41:46 AM
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
Quote from: ollydbg on November 20, 2012, 12:24:33 PM
Quote from: jens on November 20, 2012, 11:46:04 AM
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.
Quote from: MortenMacFly on November 20, 2012, 12:58:35 PM
Quote from: ollydbg on November 20, 2012, 12:24:33 PM
Quote from: jens on November 20, 2012, 11:46:04 AM
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...
Quote from: MortenMacFly on November 20, 2012, 02:38:13 PM
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.
Quote from: jens on November 20, 2012, 02:58:39 PM
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.
Quote from: MortenMacFly on November 20, 2012, 02:44:27 PM
Quote from: MortenMacFly on November 20, 2012, 02:38:13 PM
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
Quote from: MortenMacFly on November 20, 2012, 05:34:02 PM
Quote from: jens on November 20, 2012, 02:58:39 PM
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
Quote from: killerbot on November 20, 2012, 10:54:47 PM
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
Quote from: Martin K. on November 20, 2012, 08:43:09 PM
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?!).
Quote from: MortenMacFly on November 21, 2012, 06:29:18 AM
Quote from: Martin K. on November 20, 2012, 08:43:09 PM
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?
Quote from: jccddd on November 21, 2012, 03:11:07 PM
The bug still exists at rev8587.
Quote from: oBFusCATed on November 21, 2012, 03:12:57 PM
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.