Bug in BaseObject::GetMg()?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 22/09/2012 at 01:02, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
Can uninitialized variables cause a crashing problem?
I saw this thread on stack overflow:
http://stackoverflow.com/questions/5368587/an-error-only-occurs-in-release-mode
... where someone replied:

<span ="Apple-style-span" style="font-family: Arial, 'Liberation Sans', 'DejaVu Sans', sans-serif; font-size: 14px; line-height: 18px; border-collapse: collapse; ">99% of the time it is some of your variables are not initialized, check very carefully.</span>

I do have some warnings about uninitialized variables in the compile.
Adios,
Cactus Dan

If it is "uninitialized" and not "unused" - of course, as depending on the accidental memory content of this variable strange things can happen; you might write or read data that you haven't allocated or that don't contain your data at all (e.g. program code, saved register data, stack, ...)

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2012 at 08:24, xxxxxxxx wrote:

Howdy,

OK, I've made sure that I initialized all variables that produced the uninitialized warning, in fact I've corrected every compiler warning, and it's still crashing.

Several of my plugins are crashing, and all of them are crashing on a line that is using the "=" operator with a Matrix.

Why is it only crashing with a Matrix operation, and in the context of an expression tag plugin?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2012 at 08:48, xxxxxxxx wrote:

Howdy,

Wait a minute.

What is going on here:

Is it saying that it lost the pointer to the NodeData()?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2012 at 17:20, xxxxxxxx wrote:

Howdy,

Well, the only way I can get the plugins to not crash in Windows 64 bit is to disable optimization.:frowning2:

Will that cause any problems?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2012 at 23:46, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
Well, the only way I can get the plugins to not crash in Windows 64 bit is to disable optimization.:frowning2:
Will that cause any problems?
Adios,
Cactus Dan

Dan, what looks really sus**cious is to see the "this" pointer being NULL.

Either that class couldn't be created, or it was already destroyed, or you've overwritten memory (and trashed the this pointer).

But it's quite hard to draw any conclusions when just seeing a screenshot of local variables.

If the plugin "works" when disabling optimizations, then in majority of the cases you have a programming error, not a compiler error.

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/09/2012 at 05:42, xxxxxxxx wrote:

Howdy,

Well the main question is, is it safe to release the unoptimized compiled version for now so that the users can use the plugins in 64 bit without crashing while I try to figure out what's wrong with my code?

So, why does it only crash in Windows 64 bit? It works fine in Windows 7 32 bit with the optimization on, it works fine on Mac OS and it works fine in all other versions of Cinema 4D all the way back to R9.6. I'm using the same source code files for all versions, because I have them setup with preprocessor directives to check the API_VERSION.

The problem is that I'm not experienced enough to know where else to look. As I mentioned above I've gone through and initialized all uninitialized variables so that the compiler isn't giving me any warnings or errors. I've also put a breakpoint in the code so that I can step through it and check the values of the variables.

What are some other things for me to check? Is it possible that another one of my plugins could be overwriting code in the plugin that I'm debugging?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/09/2012 at 10:49, xxxxxxxx wrote:

Howdy,

Also, what about this warning:

1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5) : warning MSB8012: TargetPath(C:\MAXON\CINEMA 4D R14\plugins\CD_Constraints1.5\cinema4dsdk.cdl64) does not match the Linker's OutputFile property value (C:\MAXON\CINEMA 4D R14\plugins\CD_Constraints1.5\CDConstraintsR14.cdl64). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5) : warning MSB8012: TargetName(cinema4dsdk) does not match the Linker's OutputFile property value (CDConstraintsR14). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

I'm sure it has to do with the fact that I've changed the name of the output file to my plugin's name (never got that warning in previous versions of MSVC). The names of the project files are still cinema4dsdk, but I've been simply doing that all along because changing the names of the project files never worked for me in the past (probably did something wrong).

Could that be causing any issues, too? (I've always been kind of lost with MSVC, Xcode I understand fine).

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/09/2012 at 11:07, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy, [... ]I'm sure it has to do with the fact that I've changed the name of the output file to my plugin's name (never got that warning in previous versions of MSVC). The names of the project files are still cinema4dsdk, but I've been simply doing that all along because changing the names of the project files never worked for me in the past (probably did something wrong). 
Could that be causing any issues, too? (I've always been kind of lost with MSVC, Xcode I understand fine).
Adios,
Cactus Dan

This looks like a "feature" of VS 2010 - see here: http://stackoverflow.com/questions/4494028/warning-msb8012-make-sure-that-outdir-targetname-and-targetext-prope

If the output directory and the Link->output file don't match, you get this warning.

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/09/2012 at 11:20, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
Well the main question is, is it safe to release the unoptimized compiled version for now so that the users can use the plugins in 64 bit without crashing while I try to figure out what's wrong with my code?
So, why does it only crash in Windows 64 bit? It works fine in Windows 7 32 bit with the optimization on, it works fine on Mac OS and it works fine in all other versions of Cinema 4D all the way back to R9.6. I'm using the same source code files for all versions, because I have them setup with preprocessor directives to check the API_VERSION.
The problem is that I'm not experienced enough to know where else to look. As I mentioned above I've gone through and initialized all uninitialized variables so that the compiler isn't giving me any warnings or errors. I've also put a breakpoint in the code so that I can step through it and check the values of the variables.
What are some other things for me to check? Is it possible that another one of my plugins could be overwriting code in the plugin that I'm debugging?
Adios,
Cactus Dan

What 's different in 64 bit: The compiler can use more registers and does use less stack variables and therefore can do more optimizations. Most likely the 32 bit version contains the same bug and you'd been lucky that it hasn't popped up until now.

It's possible but not very likely that another plugin (or a - very rare - compiler bug) is causing this, but from experience I'd suggest investigating your plugin (single-stepping with the debugger/setting watch points) first.

What you might try is this tool (it's expensive if you plan buying it, but you can use the trial for without limitations of the functionality until you've "used" the a certain number of clicks on its output) : http://www.viva64.com/en/pvs-studio/

They do static code analysis of your source (which takes some time, if you haven't the fastest machine) and sometimes they are able to spot quite interesting bugs - you will also have to deal with false positives too (you've to check them all...), but that 's a part of static analysis.

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/09/2012 at 11:23, xxxxxxxx wrote:

Howdy,

Hehe, thanks. Right after posting that, I figured out how to change the names of the project files and get it to work. I reckon I never took the time to figure it out before because doing the PC compile was always the last minute thing I did before sending a plugin to the beta testers. :blush:

All of my initial development and testing is always done on the Mac.

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 04/10/2012 at 14:44, xxxxxxxx wrote:

Howdy,

Originally posted by xxxxxxxx

...What you might try is this tool (it's expensive if you plan buying it, but you can use the trial for without limitations of the functionality until you've "used" the a certain number of clicks on its output) : http://www.viva64.com/en/pvs-studio/

They do static code analysis of your source (which takes some time, if you haven't the fastest machine) and sometimes they are able to spot quite interesting bugs - you will also have to deal with false positives too (you've to check them all...), but that 's a part of static analysis...

OK, I downloaded the demo and ran it on my project:

... but as you can see the number of "Fails" is 0. About half of the warnings are from the api project code and the other half are from my code. There were warning levels 1, 2 and 3 in both the api project code and my code.

I also found an open source static code analysis application on source forge:
http://cppcheck.sourceforge.net/

... downloaded that and ran a check on my source code:

... and it flagged 2 as errors while the rest were flagged as "Style" warnings. The 2 errors were accessing a class pointer's member functions before checking for a valid pointer, one was getting a BaseSelect, and the other was getting the calculated phong normals array (which I initially figured were guaranteed not to be NULL). But even after correcting those 2 errors, it still crashes when compiler optimization is enabled.

I did a little reading on the PVS Studio site about false positives regarding preprocessor #ifdef's, but I'm not sure if that applies. The only preprocessor directives I'm using that would affect R14 are:

#if API_VERSION < 12000
//compile this code
#else
//compile this code
#endif

... and those seem to compile fine in previous versions.

One thing I did notice though is when the plugin is compiled with the optimization enabled and it crashes, the code under less than R12 directive is not grayed out, but when I compile it with the optimization disabled and add a break point in the source code, when it breaks, the code under less than R12 directive is grayed out. I'm not sure if that means anything or not.

So, what do I check now?

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 05/10/2012 at 05:19, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,

Originally posted by xxxxxxxx

...What you might try is this tool (it's expensive if you plan buying it, but you can use the trial for without limitations of the functionality until you've "used" the a certain number of clicks on its output) : http://www.viva64.com/en/pvs-studio/ 
They do static code analysis of your source (which takes some time, if you haven't the fastest machine) and sometimes they are able to spot quite interesting bugs - you will also have to deal with false positives too (you've to check them all...), but that 's a part of static analysis...

OK, I downloaded the demo and ran it on my project:

... but as you can see the number of "Fails" is 0. About half of the warnings are from the api project code and the other half are from my code. There were warning levels 1, 2 and 3 in both the api project code and my code.

"Fails: 0" just means: There had been no files that PVS-Studio couldn't analyze.

Forget about Warning Level 3, that's most of the time hyperbole. The interesting part is the 45 Warnings on level 1 and the 219 warnings on Level 2. Have a look at those ones (and for sure you'll find false positives there - I told you so).

Regarding API_VERSION check: Most likely an IDE bug - you can use the #error statement to check if the < 12000 part isn't used.

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 06/10/2012 at 12:04, xxxxxxxx wrote:

Howdy,

Well, no luck so far. I've checked every warning (nice that PVS_Studio shows the file and line number so I don't have to waste clicks) and these are the only warning types I'm getting in my code at level 1 and 2 along with a typical example from my source code.

1. Dangerous Magic Number 4 used:

AddChild(C_CLAMP_AXIS, 4, GeLoadString(C_CLAMP_NY)); // from GeDialog::AddChild()

2. Implicit conversion of 'bsCount' to memsize type in an arithmetic expression:

LONG *ptInd = (LONG* )GeAlloc(sizeof(LONG)*bsCount); // bsCount is the result of BaseSelect::GetCount()

3. Incorrect index type: ptInd[not a memsize-type]. Use memsize type instead:

ptInd[ptCnt] = i; // "ptCnt" and "i" are of type LONG

4. The bool type is implicitly casted to the class type:

yAxis = !(zAxis % xAxis); // "!" is using the "Normalize" operator of the Vector

... this one also for "!" using the "Inverse" operator of the Matrix

5. Implicit type conversion second argument 'OBJECT' of function 'SetLong' to 32-bit type:

tData->SetLong(COORD_SPACE,OBJECT); // from BaseContainer::SetLong()

I think warnings 1, 4 and 5 can probably be totally ignored (I see the same ones in the API source), but I'm not sure I understand exactly what warnings 2 and 3 are telling me. From the documentation, it sounds like warning number 2 might be an issue with 64 bit because it may not be allocating the array space properly. Could this be the source of the problems?

Adios,
Cactus Dan
Edit:
P.S. Why is it that the Mac version 64 bit doesn't have any issues? Is it because it uses the GCC compiler?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/10/2012 at 00:18, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
Well, no luck so far. I've checked every warning (nice that PVS_Studio shows the file and line number so I don't have to waste clicks) and these are the only warning types I'm getting in my code at level 1 and 2 along with a typical example from my source code.
1. Dangerous Magic Number 4 used:

AddChild(C_CLAMP_AXIS, 4, GeLoadString(C_CLAMP_NY)); // from GeDialog::AddChild()

2. Implicit conversion of 'bsCount' to memsize type in an arithmetic expression:

LONG *ptInd = (LONG* )GeAlloc(sizeof(LONG)*bsCount); // bsCount is the result of BaseSelect::GetCount()

3. Incorrect index type: ptInd[not a memsize-type]. Use memsize type instead:

ptInd[ptCnt] = i; // "ptCnt" and "i" are of type LONG

4. The bool type is implicitly casted to the class type:

yAxis = !(zAxis % xAxis); // "!" is using the "Normalize" operator of the Vector

... this one also for "!" using the "Inverse" operator of the Matrix
5. Implicit type conversion second argument 'OBJECT' of function 'SetLong' to 32-bit type:

tData->SetLong(COORD_SPACE,OBJECT); // from BaseContainer::SetLong()

I think warnings 1, 4 and 5 can probably be totally ignored (I see the same ones in the API source), but I'm not sure I understand exactly what warnings 2 and 3 are telling me. From the documentation, it sounds like warning number 2 might be an issue with 64 bit because it may not be allocating the array space properly. Could this be the source of the problems?
Adios,
Cactus Dan
Edit:
P.S. Why is it that the Mac version 64 bit doesn't have any issues? Is it because it uses the GCC compiler?

2. & 3. means: You've a resulting data type size (32 bit) which is smaller than the operand size of the method, which can result in trashed memory if exceeding the 2 GB range.
E.g.:
- in 2. you're multiplying a signed and unsigned 32 bit value (quiz game: how does that behave when going > 2 GB?) that is extended according to the C/C++ rules to VLONG (which is a signed 64 bit value).
- in 3. you're using a signed 32 bit index which is extended to 64 bit - and therefore will point before the allocated memeory when going > 2 GB (as the then negative 32 bit signed integer is extended to a negative 64 bit signed integer).

4. Is a (documented) weakness of the static analyzer handling certain operator overloads.

Why this doesn't happen on the Mac is hard to say with the few pieces of information (about the source and the crash) that we've on the table. The Mac version uses the Clang compiler (XCode 4.x) or gcc (XCode 3.x), while you're using MS's compiler on Windows, but besides that Windows also does a different job at memory randomization (ASLR), the virtual memory managers and the and the memory management work different, ... . You could try to use the INtel C++ compiler on Windows in release mode (that is what we do too), but this one has its own quirks.

I fear you've to track that down in single step mode, probably also adding a few magic safety words before and behind memory allocated structures and inside classes that you check to see, if you find a memory trasher.

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/10/2012 at 04:27, xxxxxxxx wrote:

Howdy,

Well, crap! Stepping through the optimized code gives me unexpected results. For example, as I'm stepping through a for loop, it jumps out of the for loop to several lines above the "for" statement. Plus it's not listing all the local variables within the function in the Locals panel. :astonished:

When I step through the unoptimized code, everything behaves as expected and all the local variables are listed in the Locals panel. This is going to take forever to figure out and I fear I may simply have to settle for unoptimized compiles for 64 bit Windows. :cry:

Adios,
Cactus Dan

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 07/10/2012 at 08:11, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
Well, crap! Stepping through the optimized code gives me unexpected results. For example, as I'm stepping through a for loop, it jumps out of the for loop to several lines above the "for" statement. Plus it's not listing all the local variables within the function in the Locals panel. :astonished:
When I step through the unoptimized code, everything behaves as expected and all the local variables are listed in the Locals panel. This is going to take forever to figure out and I fear I may simply have to settle for unoptimized compiles for 64 bit Windows. :cry:
Adios,
Cactus Dan

Of course it does - the compiler is optimizing the code; moving variable assignment if possible, putting stuff into registers, computing constant expressions and moving them out of loops, etc.

To debug release code you often have to switch into Disassembly view - you can do that in the context menu of the debugger (available in the Pro or bigger versions of Visual studio); just try it after reaching a breakpoint in your code and then opening the context menu...

The disassembly view shows you the c++ code plus the assembly code the compiler actually produced for it - and you can set breakpoints in the assembly code and single-step trough it; opening the cpu register window is highly recommended, as depending on the compiler optimization the usual C++ variable view might not show you the variables anymore.

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/10/2012 at 15:08, xxxxxxxx wrote:

Howdy,

Here is something interesting:
http://msdn.microsoft.com/en-us/library/chh3fb0k.aspx

If I add the optimize pragmas around the offending function like this:

#pragma optimize("", off)
OffendingFuntion()
{
	// function code where it crashes
}
#pragma optimize("",on)

... it doesn't crash anymore.

Do you know much about using this pragma?

Adios,
Cactus Dan