Bug in BaseObject::GetMg()?

Helper

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

On 19/09/2012 at 06:03, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R14
Platform:   Windows ;
Language(s) :     C++ ;

---------
Howdy,

Seems there is a bug in BaseObject::GetMg() on PC in R14.

The code in my tag has a simple call to get the global matrix of the object:

Matrix opM = op->GetMg();

... and the returned matrix has some corrupt values:

+  off {x=69.999984741200265 y=6.1035166921724721e-005 z=-18.397233963026036 } LVector  
+  v1 {x=-0.99722000169095248 y=7.807294109521e-316#DEN z=4.343524595297e-311#DEN } LVector  
+  v2 {x=0.00000000000000000 y=0.00000000000000000 z=8.306716217468e-316#DEN } LVector  
+  v3 {x=2.647729800154e-314#DEN y=0.00000000000000000 z=9.490366281069e-316#DEN } LVector

What's going on here?

Edit:
This is only happening on PC 64 bit. The PC 32 bit is fine, and also the Mac version is fine.

Adios,
Cactus Dan

Helper

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

On 19/09/2012 at 09:55, xxxxxxxx wrote:

I see that a lot. It's not a bug - well, not really, more an arithmetical error in that you notice that those 'corrupt' values all end in 'e-nnn' which just means that the number is extremely small, approaching zero in fact. It happens when a value is expected to be zero but isn't quite, presumably due to the maths hardware giving rounding errors.

It doesn't seem to cause a problem for the code so I just ignore it, it's just an irritating artefact.

Edit: the '#DEN' is explained at http://en.wikipedia.org/wiki/Denormal_number.

Steve

Helper

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

On 19/09/2012 at 10:28, xxxxxxxx wrote:

Howdy,

But it is causing a crash, especially when those values get passed to another function. The crash happens in the other function.

My plugins are working fine in 32 bit PC and on Mac OS, but in 64 bit PC they're crashing.

Edit:
Also, the crash only happens in the release version, not the debug version.

Adios,
Cactus Dan

Helper

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

On 19/09/2012 at 13:03, xxxxxxxx wrote:

That's odd, I can't explain that. It certainly doesn't crash for me, so I'm not sure what would be going on there, or why it would be any different in the release version.

Maybe Maxon support could comment?

Helper

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

On 19/09/2012 at 13:27, xxxxxxxx wrote:

Howdy,

Here's another strange thing. At the point that it crashes the xyz values of the passed vector (opM.off) are different than they are in the calling function.

In the calling function the Vector values are:

+  opM.off {x=69.999984741200265 y=6.1035166921724721e-005 z=-18.397233963026036 } LVector

... and in the called function the passed Vector has these values:

+  o {x=8.325457510799e-316#DEN y=8.170182707844e-316#DEN z=2.121995790471e-314#DEN } LVector

How can that be?

Adios,
Cactus Dan

Helper

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

On 19/09/2012 at 13:33, xxxxxxxx wrote:

Now that is also something I have run into (no crash, just apparently incorrect values). It only seems to happen with vectors. I spent some time trying to figure it out and couldn't, so I always pass a pointer to the vector now, rather than passing by value, which seems to resolve it.

Steve

Helper

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

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

Howdy,

Here is the crash error message:

... and the debugger points to the second line of the called function:

Matrix GetRPMatrix(LONG pole, Vector o, Vector g, Vector p)
{
	Matrix m = Matrix();
  
	m.off = o; // here's where it crashes

It just doesn't make any sense, because that line is simply setting the value of m.off equal to the passed Vector o.

Why?

Adios,
Cactus Dan

Helper

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

On 20/09/2012 at 01:19, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
Here is the crash error message:

... and the debugger points to the second line of the called function:
[/DIV][DIV]Matrix GetRPMatrix(LONG pole, Vector o, Vector g, Vector p)[/DIV][DIV]{[/DIV][DIV]     Matrix m = Matrix();[/DIV][DIV][/DIV][DIV]     m.off = o; // here's where it crashes[/DIV][DIV]
It just doesn't make any sense, because that line is simply setting the value of m.off equal to the passed Vector o.
Why?
Adios,
Cactus Dan

Dan, DENs are perfectly valid and the FPU (or SIMD) engine can work with it properly.

What might cause trouble in are cases where you've special handling for a float value being EXACTLY "0.0". The DEN is close too (and in some situations like a division could create a div by zero too), but it ain't id. with "0.0". Therefore a cast from float to int where you're using that casted int as index later on could create values you're not expecting.

That would be a good reason for a crash, but that 's hard to find out without a compiling (and crashing) sample code - I'm pretty sure that the debugger is fooling you here and you see a side effect of the crash, not the real issue.

Best regards,

Wilfried

Helper

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

On 20/09/2012 at 05:39, xxxxxxxx wrote:

Howdy,

So, are you saying that the debugger isn't pointing to what's causing the crash, probably because the real problem has corrupted an address somewhere?

Adios,
Cactus Dan

Helper

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

On 20/09/2012 at 06:48, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Howdy,
So, are you saying that the debugger isn't pointing to what's causing the crash, probably because the real problem has corrupted an address somewhere?
Adios,
Cactus Dan

That 's my guess (and why I sugested checking things like float -> int cast, loops with comparison the only exit when "0.0" is reached, etc.).

Best regards,

Wilfried

Helper

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

On 21/09/2012 at 11:33, xxxxxxxx wrote:

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:

99% of the time it is some of your variables are not initialized, check very carefully.

I do have some warnings about uninitialized variables in the compile.

Adios,
Cactus Dan

Helper

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:

99% of the time it is some of your variables are not initialized, check very carefully.

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

Helper

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

Helper

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

Helper

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

Helper

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

Helper

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

Helper

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

Helper

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

Helper

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