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.