StackOverFlowException: Is it programming error (recursion) or not enough maximum default stack size?

问题

I am trying to get virtual machine configuration info for a VM in VMware using webservices SDK approach. I was able to get virtual machine configuration info from simple console application, command line interface (Powershell) of my tool. However when i tried to do the same in my UI (MMC-Snapin), I am getting a StackOverflowException. Can you please help me or give me suggestions how to debug the error?

Please note that same code works with console/commandline (powershell). Not from MMC UI (i took care of serialization). Is it something to do with stack limitations with MMC? I dont have any clue how to debug this. Any ideas/suggestions really help?

I have given the code below. Please note that as soon as i un-comment "config" property from property collection I am getting stackoverflow from MMC Snap-in (UI).

Regards, Dreamer

In other words, do i need to increase the stack size for MMC UI?

Increasing the max stack size of the thread to 8MB (8388608), not throwing the exception. But I am not happy with the fix as what if bigger data comes?

In fact setting it to 1MB stack size is working. So probably the default stack size for MMC is low. Not sure whether increasing to 1MB causes any side affects though. Any comments/thoughts?

Btw, the exception is coming from VMWARE SDK (vimservice/vimserializers/system.xml) which I have no control over.

Regards, Naresh

TraversalSpec datacenterVMTraversalSpec = new TraversalSpec();
                datacenterVMTraversalSpec.type = "Datacenter";
                datacenterVMTraversalSpec.name = "datacenterVMTraversalSpec";
                datacenterVMTraversalSpec.path = "vmFolder";
                datacenterVMTraversalSpec.skip = false;
                datacenterVMTraversalSpec.selectSet = new SelectionSpec[] { new SelectionSpec() };
                datacenterVMTraversalSpec.selectSet[0].name = "folderTraversalSpec";

                TraversalSpec folderTraversalSpec = new TraversalSpec();
                folderTraversalSpec.name = "folderTraversalSpec";
                folderTraversalSpec.type = "Folder";
                folderTraversalSpec.path = "childEntity";
                folderTraversalSpec.skip = false;
                folderTraversalSpec.selectSet = new SelectionSpec[] { new SelectionSpec(), datacenterVMTraversalSpec };
                folderTraversalSpec.selectSet[0].name = "folderTraversalSpec";

                    PropertyFilterSpec propFilterSpec = new PropertyFilterSpec();
                    propFilterSpec.propSet = new PropertySpec[] { new PropertySpec() };
                    propFilterSpec.propSet[0].all = false;
                    propFilterSpec.propSet[0].type = "VirtualMachine";
                    propFilterSpec.propSet[0].pathSet = new string[] { "name", 
                        //"config", //TODO: investigate including config is throwing stack overflow exception in MMC UI. 
                        "summary",
                        "datastore", 
                        "resourcePool" 
                    };

 propFilterSpec.objectSet = new ObjectSpec[] { new ObjectSpec() };
                propFilterSpec.objectSet[0].obj = this.ServiceUtil.GetConnection().Root;
                propFilterSpec.objectSet[0].skip = false;
                propFilterSpec.objectSet[0].selectSet = new SelectionSpec[] { folderTraversalSpec };

                VimService vimService = this.ServiceUtil.GetConnection().Service;
                ManagedObjectReference objectRef = this.ServiceUtil.GetConnection().PropCol;
                PropertyFilterSpec[] filterSpec = new PropertyFilterSpec[] { propFilterSpec };
                ObjectContent[] ocArray = vimService.RetrieveProperties(objectRef, filterSpec);

Regards, Dreamer

回答1:

The easiest way to get a stack overflow exception is infinite recursion. That would be the first thing I would look for. Do you have a stack trace with your exception? That would let you know immediately if that's the case.

回答2:

For technical reasons, the amount of stack space is fixed. This means that particularly RAM-heavy recursive algorithms are in trouble: it is always possible that certain inputs will overrun the threshold, and the program will crash despite lots of free RAM still being available.

On Windows, the memory for stack is reserved, but typically not committed (except in .NET). This means that if your program wants a 100 MB large stack, only the address space is used up. Other programs can still use the same amount of RAM as they could before you declared that you might use up to 100 MB of stack.

In .NET, because the stack space is committed, the total amount of memory other programs can allocate does go down by 100 MB in this case, but no physical RAM is actually allocated until your algorithm genuinely needs it.

So increasing the stack size is not as bad as you might think, especially if you're not coding in .NET.

I've had an algorithm run into a stack limitation. Unfortunately our algorithm was part of a library. Not wanting to require our callers to start their threads with a larger stack, we rewrote the algorithm to use an explicit stack in a loop, instead of recursion. This made the algorithm slower and much harder to understand. It also made debugging nearly impossible. But it did the job.

So rewriting with explicit stack is one possibility, but I recommend against it unless you absolutely must handle the incoming data no matter how large it is, up to the limit of the available RAM, and are not happy with setting a smaller hard limit.

来源：https://stackoverflow.com/questions/9027955/stackoverflowexception-is-it-programming-error-recursion-or-not-enough-maximu

标签

.net

multithreading

web-services

vmware