08-09-2011 12:09 PM
'Stack overflow' fault at 0x00471570
I am now receiving a stack overflow error in my program when updating to the 2010 sp1 update. The error only occurs If immediately after the program opens, I click a couple of drop down menus. This is a big issue in my program as I have saved states which can be loaded, and I will do many things immediately on start up.
I know I can just change my stack size manually to alleviate the issue in my build options, but wanted to see if there were other recommended methods such as start up delays, or variable definitions. I feel just randomnly increasing stack size is probably not the best engineering approach, although maybe my stack size default is small compared to other complex programs.
Build Options for Release: (note issue only seen here)
__cdecl
max stack size 50000000
base address x00400000
profiling disabled
lean and mead
uninitalized variable - conservative
detect unreachable code, unreferenced identifiers, assignments in condit. exps
clang - all selected
Build options for debug
Same as above except:
Max stack size is 10000000
standard debug level
Thanks,
Nick
08-09-2011 12:24 PM
Hey Nick -
I'm very interested in reproducing the behavior you're seeing here. Is there any way you can post some code that reproduces?
NickB
National Instruments
08-09-2011 12:38 PM
After some investigation, it may not be totally from updating to SP1 but not 100 percent positive.
I have a lot of unitialized variables and one thing I did change is having 5 double pointer arrays go from 36 to 96.
double *array1[36] -> 96
Sadly, those five variables seem to break it, even though I never initialize these before it crashes. I can get it to trigger repeatedly too by selecting my two drop down boxes then moving my mouse in circles.
That should have been the only change on initialized variables. Is there a way to track stack size on the fly or at least see how much the program pulls?
nickb, can I upload the program to the ni ftp? i can send .exe and dbg_exe with same stack size.
08-09-2011 12:58 PM
Another question, one of those drop down boxes will "undim" a button that has a callback. When doing this, what happens on the back end? I ask because I changed my debug stack size to match my release and it stops at the top of the button callback that gets unhidden. If that is the case then that may be the issue.
Because I make a temp array that instead of being 36*68000, is now 96*68000. (reading in unknown file size, and was somewhat lazy to implement dynamic allocation 🙂 )
Strangely, if I wait long enough after startup, then it doesn't crash either, making me wonder if CVI is trying to cleanup after program startup early on.
Thanks,
Nick
08-09-2011 03:07 PM
Hmm... I don't really feel like I have enough infomation to guess about what the cause may be. You can definitely upload the app to ftp://ftp.ni.com/incoming and I'll take a look. If you could post the entire project with source and everything, that would be best so that I can debug what I can in the release build.
I'll look at it as soon as I can -
NickB
National Instruments
08-10-2011 03:21 PM
Should be uploaded now with your name in filename.
I think you can get it to crash with the debug.exe by just opening and closing.
Thanks,
Nick
08-11-2011 11:52 AM
Hello Nick -
It looks like your array is just too big. You've declared it as essentially: double foo[96][68000];
If we do a quick calculation (96*68000*8) we'll see that the array requires 52,224,000 bytes on the stack. However, your build options are configured to allow a maximum stack size of 50,000,000 bytes. You either need to increase the maximum stack size, or dynamically allocate that array. In this case, I think I'd dynamicallly allocate such a large array.
NickB
National Instruments
08-11-2011 12:00 PM
Yea, that makes sense. Probably just need to open the file, read amount of lines, then go back to beginning to then dynamically allocate that array.
Thanks