rev 8583 crash

[Jenna]

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) .

[Martin K.]

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

[killerbot]

4 core ==> build in parallel ==> you will go down to lest then 15 minutes I think

[Martin K.]

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

[MortenMacFly]

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?!).

[jccddd]

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.

[oBFusCATed]

Is it possible to use a debugger and provide a callstack of the crash?

[MortenMacFly]

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.