Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Codeblocks crashing when closing project options dialog

(1/4) > >>

Jan van den Borst:
LS,
I have been having crashes when closing the project options dialog. Having some spare time available I started debugging and pinpointed the problem down to the file sdk\projectfile.cpp , svn rev 3664, line 281:

    Compiler* compiler = target
                            ? CompilerFactory::GetCompiler(target->GetCompilerID())
                            : CompilerFactory::GetDefaultCompiler();

The pointer is not checked against NULL. Therefore in my project file codeblocks  crashes at line 360:

fname.SetExt(compiler->GetSwitches().objectExtension);

I don't know if the pointer is to become NULL but in my case it does.
A simple:

 if (!compiler)
   return;

just after line 281 prevents the crash.

Kind regards
Jan

thomas:
That seems to be right. Although there is a check for null-ness on that variable a few lines later, the check is not good (both branches use it).

Biplab:
But I've got couple of questions.

1. Why doesn't the following code crashes?
Line 286: projectfile.cpp

--- Code: ---    if (target && ft == ftHeader && compiler && compiler->GetSwitches().supportsPCH)
--- End code ---

2. Why compiler is getting NULL value? At least it should get a Compiler.

The worst case (where compiler variable would get NULL value)
  i) could be target is NULL and no default compiler is set.
  ii) GetCompiler() is returning 0 as it can't find a proper match.

MortenMacFly:

--- Quote from: Biplab on March 05, 2007, 11:43:46 am ---1. Why doesn't the following code crashes?
Line 286: projectfile.cpp

--- Code: ---    if (target && ft == ftHeader && compiler && compiler->GetSwitches().supportsPCH)
--- End code ---

--- End quote ---
Because if compiler is NULL all following checks are *not* done. The if statement exits early if the fist boolean is false... at least this applies to GCC. Other compiler *might* handle this different.


--- Quote from: Biplab on March 05, 2007, 11:43:46 am ---2. Why compiler is getting NULL value? At least it should get a Compiler.

--- End quote ---
Actually this can easily happen. Suppose you create a copy of a compiler and setup a project based on that. Now if you open the project on another PC where this compiler (the copy) isn't setup then the compiler will usually be NULL. Another option is that the one or other (like me ;-)) might have base compilers integrated that do not exist at all. In that case opening such a project would result in the compiler being NULL, too.
In the end there is another option: Disable the compiler plugin and the compiler will always be NULL. ;-)

BTW: You can easily simulate these cases by modifying a C::B project file and setting the compiler to an invalid string like: <Option compiler="does_not_exist" />... and/or disable the compiler plugin. This reminds me that at the time Yiannis implemented the plugin activate/de-activate facility we were hunting quite some bugs with missing checks for a valid compiler. Maybe we should repeat this step from time to time. ;-)

With regards, Morten.

Biplab:
Thanks Morten for the clarification.


--- Quote from: MortenMacFly on March 05, 2007, 12:45:03 pm ---Because if compiler is NULL all following checks are *not* done. The if statement exits early if the fist boolean is false... at least this applies to GCC. Other compiler *might* handle this different.

--- End quote ---

I was doubtful about this answer. Thanks for confirming it.


--- Quote from: MortenMacFly on March 05, 2007, 12:45:03 pm ---
--- Quote from: Biplab on March 05, 2007, 11:43:46 am ---2. Why compiler is getting NULL value? At least it should get a Compiler.

--- End quote ---
Actually this can easily happen. Suppose you create a copy of a compiler and setup a project based on that. Now if you open the project on another PC where this compiler (the copy) isn't setup then the compiler will usually be NULL. Another option is that the one or other (like me ;-)) might have base compilers integrated that do not exist at all. In that case opening such a project would result in the compiler being NULL, too.
In the end there is another option: Disable the compiler plugin and the compiler will always be NULL. ;-)

BTW: You can easily simulate these cases by modifying a C::B project file and setting the compiler to an invalid string like: <Option compiler="does_not_exist" />... and/or disable the compiler plugin. This reminds me that at the time Yiannis implemented the plugin activate/de-activate facility we were hunting quite some bugs with missing checks for a valid compiler. Maybe we should repeat this step from time to time. ;-)

--- End quote ---

So it is a problem of 2nd type as I mentioned. I think we should put a MessageBox throwing some *Warning* message before returning 0 in GetCompiler() or at least throw some messages in the Debug-Log. User would come to know about this problem then.

Alternatively it can be set to return Default Compiler. :)

Regards,

Biplab

Navigation

[0] Message Index

[#] Next page