Bug in BaseObject::GetMg()?



  • 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. 😊

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

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

    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. 😲
    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. 😢
    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


Log in to reply