Stack corrupted around CNiPointers

[ClausB]

Hi,

I'm trying to convert a Measurement Studio project from 6.0 to 8.1.1 for Visual Studio 2005. It's a LabView callable DLL which uses UI components. When I run it in debug mode I get numerous Run-Time Check Failures saying that the stack is corrupted around local CNiPointers objects. I also get corruption of locals on the stack near calls to CNiGraph::GetAxes() and GetPlots(). One common thing among all the problem areas is the use of .Item() on objects of type CNiPointers, CNiAxes, and CNiPlots. In release mode I have also seen evidence of stack corruption in those areas.

Is there a problem with those NI classes or do I have some project setting wrong?

Thanks.

Claus

[JonathanN]

Hi Claus,

There shouldn't be any problems with using those Measurement Studio classes as they've been around for quite some time and we've done plenty of testing of those of those classes. Questions I have include:

- Did everything compiled and ran fine back with Measurement Studio 6.0? By that I am wondering if after you upgraded to 8.1.1, the problems started occuring?
- Do you get these stack corruption errors ever since time you run your application?
- Do they occur in the same place?
- Can you run any of our C++ UI shipping examples without issues?
- Is it possible that you can provide me with some watered-down example that demonstrates this behavior?
- What does the stack corruption error exactly say?
- When you say you are running in debug mode, are you building the DLL in debug mode and then calling that DLL from LabVIEW? Or are you building a debug version of a "testing" app that is calling into your C++ DLL and that's when errors are thrown? I'm going to need some more clarification on this part.

I assume you were using Visual Studio 6.0 and then just upgraded to Visual Studio 2005?

At this point I really can't guess as to what the problem is since I don't have a lot of infomation. My first thought is that maybe you are not properly allocating, disposing, etc resources propertly but that may not have anything to do with it. 

Best Regards,

[ClausB]

Hi, Jonathon,

Thanks for the quick response. I am happy to give you more info, including tests I've done already, and to try your suggestions. Here are anwers to your points:

- Yes, everything worked fine in 6.0. When it came time to upgrade, I first tried to build it under Visual Studio 2005 with the original Meas. Studio 6.0 headers and libs but it wanted to link the old MFC libs and could not find them. So I installed Meas. Studio 8.1.1 (I was afraid to install 8.1.2 from the December CD set because of "risk of bodily injury") and deleted the old headers and libs from the project. It recompiled and linked just fine.

- Yes, the stack corruption breakpoints happened the first time I ran in debug mode. When I turned off the stack checker, I got some bogus failures warning of using uninitialized variables. I say "bogus" because when I step through the code, the variables are clearly initialized. I suspect that the unchecked stack corruption is confusing the variable checker. When I turned that off as well, the debug code worked correctly. However, the release build still failed. I added some tracing dumps to the release build and saw that a local variable called "bRet" was being clobbered by this unrelated line of code:

m_graph.GetAxes().Item(1).SetMinMax(m_dXAxisMin, m_dXAxisMax);

but only in release mode - the debug build did not change the value of bRet! I took that as more evidence of stack corruption.

- Yes, the stack check breakpoints always occur in the three places I mentioned in the first post and the release mode failure always occurs as above (given the same app test conditions). Another interesting test result is that, if I turn on speed optimization, then the release build does not fail as above. Rather, it causes the LabView app to abruptly exit completely without any dialog or warning!

- I will try to build and run a similar NI example. If that works fine, I'll try to strip down my project and demonstrate the failure.

- The error says "Run-Time Check Failure #2 - Stack around the variable 'pointers' was corrupted." The local variable declaration is:

CNiPointers pointers = m_sliderWnd.GetPointers();

If I stick a "return;" just after that line, I get the same message but if I put "return;" just before that line, I get no error there!

- I am calling the debug DLL from LabView. And the debug DLL is calling release builds of the Meas. Studio libraries. Is there any way to link in debug versions of these libs? It would be great to step through some of the NI code (at least the top, non-proprietary layers) like you can with MFC libraries.

So I hope you can see why I suspect true stack corruption within the calls into those NI classes. Maybe I have some build setting wrong. This project was automatically converted by Visual Studio 2005 from the old one. I also tried creating a new Meas. Studio project and compared its settings with mine. I then changed some of my settings to match but to no avail. The only one I did not change was the "Struct Member Alignment". The new project used "8 Bytes" but mine requires "1 Byte" because it must parse LabView arrays and clusters.

Thank you for your attention.

Claus

 

[ClausB]

For clarity, here are declarations for the 2 lines of code in the previous post:

CNiGraph m_graph;

CNiSlide m_sliderWnd;

[ClausB]

Bingo!

I modified the NI example "Advanced Slide" to use a local CNiPointers object as below:

void

CAdvancedSlideDlg::OnPointerValueChangedSlide2(long Pointer, VARIANT FAR* Value)

{

double Low = 20.0; double Hi = 60.0; double Val;

Val = CNiVariant(Value);

CNiPointers pointers = m_Slide2.GetPointers();

if (Val > Hi)

{

pointers.Item(1).Value = Low;

m_Slide2.GetPointers().Item(2).Value = Hi;

m_Slide2.GetPointers().Item(3).Value = Val;

}

....

When I run the debug build, it works fine. If I change the project setting "Struct Member Alignment" to "1 Byte" and rebuild, I get the same stack corruption breakpoint. So it looks like I have to fix the alignment in my project. I'll post my result.

Thanks for the suggestion.

Claus

[JonathanN]

Hi Claus,

Glad you are making progress. Let me know how your additional testing goes.

Best Regards,

[ClausB]

The thing is, the project's alignment was set to 1 on NI's advice, as per this doc:

http://zone.ni.com/reference/en-XX/help/371361A-01/lvhowto/building_library_project/ 

but the new Meas. Studio seems to require 8. It's a contradiction, no? I think I can use a pragma to get around it, but is that the right solution?

[ClausB]

OK, I changed the project's alignment to 8 to make Meas. Studio happy and I used a #pragma pack(1) in the header for the LabView structs to make LabView happy. Both debug and release builds work and I'm happy. Everybody's happy! Except, maybe, the documentation person who should qualify the advice to set the DLL project alignment to 1.

Thanks, Jonathon, for your help.