Rif.: Password control crashes CVI

[kplafa]

Yes it is going to be a challenge. Built a new object file without making any changes. Tried it and works fine. Replaced with old object file and back to crashing. Grabbed object file off another system just in case something was wrong when installed and same result.

[LuisG]

By "same result" you mean that it also crashed, right?

This is very odd. There should be no difference at all between the toolbox.obj file that you created (without making changes) versus the toolbox.obj that was installed with CVI. Can you let me know exactly which version of CVI you're using (from Help>>About) and also the timestamp and size of the toolbox.obj that is crashing? Also, I assume you're running your program in 32-bit mode, right?

[LuisG]

Actually, I just remembered that the active project configuration, at the time that you compile toolbox.obj, could be impacting the code in toolbox.obj. Even though it should always build an object file without debug info, regardless of the active configuration, other customizations to your configuration could insinuate themselves into your object file.

Therefore, to be confident that you are creating a version of toolbox.obj that is as identical to the original as possible, you should launch another instance of CVI, unload your project in that instance (without transferring your build options), switch to the "Release" configuration and only then create the object file.

[kplafa]

That made a difference. File was larger and when I compiled it in release mode it was same size (263 KB) and now crashes. I'll start adding some debug messages and see if I can't pinpoint it a bit more. Actually new version is 268,463 bytes and orignal is 268,834. CVI version is 13.0.1 (201).

[kplafa]

I added simple printf statements in each line of the UnchainCtrlCallback function. It worked when I did that. Took them out of the while loop and last printf is just before the while and crashes. Added one in the begining of the while loop and still crashes with last printf the one before the loop. Added one after the else, just before the end of the while loop and works every time. Also changed the object file to optimize for space and that didn't crash. Changed back to optimize for speed and crashes until I add the printf back in. Looks like an optimization issue except runs on everything else I have?

[LuisG]

It's possible that it's an optimization issue, but it could also be a timing issue. Adding printfs changing the timing of the execution and that can sometimes be enough to affect the reproducibility of the bug. Or it could be a combination of both.

If you print to a file (fprintf) instead of printing to standard output that usually affects timing a lot less, so it can be a good alternative. You just have to remember to flush every time you print, since you want to make sure that the file has all of your logging output right up to the moment when it crashes.

As you print, you should also print the value of the currLink pointer. A bad pointer is almost certainly the immediate reason for the crash in this while loop, so by printing it you can check its value both in cases where it crashes and when it doesn't. Keep in mind that even when the pointer is bad, a crash might not happen. It all depends on where the bad value lies relative to the address space of the process.

In any case, with the very simple example that you sent me earlier, the value of currLink at that point should be NULL. If it's anything other than NULL, then something else is going on that we need to investigate further.

[kplafa]

I was pulle doff this problem for a while and just getting back to it. I checked and currLink is NULL. Changed to use fprintf statements as shown in attached and crashes again. The debug file shows up to #5 before it crashes and never shows the period. If I comment out the three lines as shown in the attachment then runs fine. Add any one (or more) of the three lines back in and crashes.

[LuisG]

That code path doesn't make sense (the period should not be shown, but #6 should), so at this point I can't see any alternative to an optimization bug -- although even then, I don't understand why it only happens in one PC.

The value of currLink is expected to be NULL. Therefore, the while-loop immediately after #5 should not execute. This looks as if the crash happened while evaluating the while-loop condition. But that should also not happen, since the && operator evaluates from left to right, and so currLink->signature should never be evaluated.

You can try one other thing, which is to try doing the same test with each of the five different optimization levels. To change the optimization level, go to Options>>Build Options>>Configuration Options, set Configuration to Release, and then change the Optimization Level control. Let me know if there is a consistent difference in behavior between them.

[kplafa]

Tried the different optimization levels. Program runs fine with no optimization or optimized for space. Fails for each of the speed optimizations, however differently for each? Using speed level 1 or 3 and fails before I can enter the password. I didn't try to figure out where yet. Speed level 2 gives the failure after #5 prints to the text file without getting any further. At this point I think it might just be best to trash the PC as don't have any issues with others. Everything else works fine on this one, but obviously something is wrong.

[LuisG]

Well, I'm almost out of ideas, so if you think abandoning this PC is a viable option for you, then that's definitely something to consider. If you'd like to continue investigating, the next step would be to do the following:

1. Generate a map file for your project (Build>>Target Settings>>Generate map file, while making sure that the active configuration in the Target Settings dialog is Release. Then, attach here the the map_file.txt that is generated in your cvibuild.<project name>/Release folder.
2. Also attach here the last version of toolbox.obj that you compiled before building your project. This object file is also in the cvibuild.<project name>/Release folder.
3. Confirm that the crash is still happening in address 0x00422DB1 (this is the address that you initially reported when you attached errors.txt). Make sure you generate the same errors.txt when you reproduce the crash after having rebuilt your project the last time.

The combination of the map file, the object file and the crash address should allows us to pinpoint exactly which assembly instruction generated the fault. This might or might not clarify what exactly the optimization problem is, but to be honest, it won't necessarily suggest any obvious workaround that would help you now.

In all likelihood, if you want to make it work on this PC, you'll have to either use a non-optimized version of toolbox.obj, or alternatively, slightly rewrite the code in the UnchainCtrlCallback function (without changing its logic, of course) until the optimization bug no longer happens. For example, you could replace the while-loop with an if-statement with a goto at the end, which would allow you to break up the condition into three smaller conditions, each on its own if-statement.