none
An unhandled exception of type 'System.StackOverflowException' occurred in mscorlib.dll

    Question

  • I've already posted on the subject before with no resolution. At that time other problems moved to forefront and the exception was not that bothering it seemed. Now it occurs with astonishing regularity. After about 10-15 min run the app breaks down. It breaks down in two places: one is in the constructor of a large form, the other this line of code:

    newRow.Table.ExtendedProperties[ "maxVol" ] = Math.Max ( ( long )newRow[ "Volume" ], ( long )newRow.Table.ExtendedProperties[ "maxVol" ] );

    This is wheer it happened las time.

    No more information is provided. No stackTrace, nothing.

    Could it be the issue of corruption in mscorlib.dll? If so, how can I replace it? Shall I erinstall Vista? Or there are simpler ways?

    Thanks.
    AlexB
    Friday, September 11, 2009 2:04 PM

Answers

  • ALOT MORE INFO needed :)


    Alex, this is what i have learned about the StackOverFlow:


    the "stack" is a list of the functions you call at any given time in your application. (but not that you 'Have Called')

    when you call Function A it is put into the stack, then if Function A Calls Function B, Function B Gets Put into the Stack.

    BUT when Function B Is Completed, it is then removed from the stack, and the stack only shows Function A.


    A StackOverFlow Exception occurs when the Stack....OverFlows :P (when the list gets to long)
    this is USUALLY caused by a function being called recursively OR a set of functions in an infinite loop

    Recursive:

            public void GetControls(Control ctl)
            {
                if (ctl.HasChildren == true)
                {
                    foreach (Control child in ctl.Controls)
                    {
                        GetControls(child);
                    }
                }
                if (ctl.Name.EndsWith("CheckBox"))
                    ((CheckBox)ctl).CheckedChanged += new EventHandler(checkboxHandler);
            }

    as you can see, GetControls loops through all the controls, BUT IF THEY HAVE CHILD CONTROLS, it runs itself agian with each child control, which then checks to see if those have child controls...etc

    this is a simple iteration, which with 1 form, with 20 controls would only be called 20 times, only putting in 21 entries to the stack (the one that initially called the function as well).

    but what if each control had 7 additional functions done to it Now That Number Jumps to (20 * 7) + 1 = 141 which is still low in regards to the stack, but you get the idea.

    if there are too many controls on the form (which btw would be...highly unlikely) the stack will fill up.








    infinite Loop:


    this one is easy to model:

    public void FunctionA
    {
         FunctionB;
    }
    
    public void FunctionB
    {
         FunctionC;
    }
    
    public void FunctionC
    {
         FunctionA;
    }



    and while its obvious here, it may not be so obvious in your code, especially when the # Of lines of code jumps high.

    function A calls Function B Which Calls Function C Which Calls Function A Which Calls Function B.....etc....



    you should get the stack trace from VS ( when the exception occurs Goto Debug>Windows>Call Stack)

    the function that appears like 10,000 times....is where your problem is :)






    Any and All code is provided only as a guide. - learning visual basic
    Friday, September 11, 2009 2:47 PM
  • Hi Alex,

    That is where it dies, but may not be the culprit, are you calling this method/operation in a recursive fashion? I surmise at least you are in a large looping operation?

    Long story short, more info needed...


    William Wegerson (www.OmegaCoder.Com )
    Friday, September 11, 2009 2:23 PM
  • Can you try adding an UnhandelledExceptionHandler into the AppDomain and see  if you get a stacktrace over there:

            public void InstallUnhandelledExceptionHandler()
            {
                AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
            }
    
    
            private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
            {
                Tracing.Trace(TraceCategories.Error, true, "Unhandelled exception encountered, details given below");
                Tracing.Trace(e.ExceptionObject as Exception,true);
            }
    

    Friday, September 11, 2009 2:41 PM
  • Gotcha...I worked on a system where we would annoint the targetted entity classes' properties with attributes describing how the data should be handled from the dataset. Basically the target column name and possibly the type of data (int/datetime/double). Then when it came time to extract the data a generic method would take the entity, reflect and enumerate the properties and thanks to the attribute extract the specific field from the dataset and cast/extract the proper data type to the object.

    Once setup the only failures occured during debug code creation time and where easily tracked thanks to the exception handling.  Plus one no longer had to extract data to properties of new tables/classes because the system did it all for you via the attributes and the generic method.

    Thanks for the clarification. :-)
    William Wegerson (www.OmegaCoder.Com)
    Saturday, September 12, 2009 2:52 AM

All replies

  • Hi Alex,

    That is where it dies, but may not be the culprit, are you calling this method/operation in a recursive fashion? I surmise at least you are in a large looping operation?

    Long story short, more info needed...


    William Wegerson (www.OmegaCoder.Com )
    Friday, September 11, 2009 2:23 PM
  • Can you try adding an UnhandelledExceptionHandler into the AppDomain and see  if you get a stacktrace over there:

            public void InstallUnhandelledExceptionHandler()
            {
                AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
            }
    
    
            private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
            {
                Tracing.Trace(TraceCategories.Error, true, "Unhandelled exception encountered, details given below");
                Tracing.Trace(e.ExceptionObject as Exception,true);
            }
    

    Friday, September 11, 2009 2:41 PM
  • ALOT MORE INFO needed :)


    Alex, this is what i have learned about the StackOverFlow:


    the "stack" is a list of the functions you call at any given time in your application. (but not that you 'Have Called')

    when you call Function A it is put into the stack, then if Function A Calls Function B, Function B Gets Put into the Stack.

    BUT when Function B Is Completed, it is then removed from the stack, and the stack only shows Function A.


    A StackOverFlow Exception occurs when the Stack....OverFlows :P (when the list gets to long)
    this is USUALLY caused by a function being called recursively OR a set of functions in an infinite loop

    Recursive:

            public void GetControls(Control ctl)
            {
                if (ctl.HasChildren == true)
                {
                    foreach (Control child in ctl.Controls)
                    {
                        GetControls(child);
                    }
                }
                if (ctl.Name.EndsWith("CheckBox"))
                    ((CheckBox)ctl).CheckedChanged += new EventHandler(checkboxHandler);
            }

    as you can see, GetControls loops through all the controls, BUT IF THEY HAVE CHILD CONTROLS, it runs itself agian with each child control, which then checks to see if those have child controls...etc

    this is a simple iteration, which with 1 form, with 20 controls would only be called 20 times, only putting in 21 entries to the stack (the one that initially called the function as well).

    but what if each control had 7 additional functions done to it Now That Number Jumps to (20 * 7) + 1 = 141 which is still low in regards to the stack, but you get the idea.

    if there are too many controls on the form (which btw would be...highly unlikely) the stack will fill up.








    infinite Loop:


    this one is easy to model:

    public void FunctionA
    {
         FunctionB;
    }
    
    public void FunctionB
    {
         FunctionC;
    }
    
    public void FunctionC
    {
         FunctionA;
    }



    and while its obvious here, it may not be so obvious in your code, especially when the # Of lines of code jumps high.

    function A calls Function B Which Calls Function C Which Calls Function A Which Calls Function B.....etc....



    you should get the stack trace from VS ( when the exception occurs Goto Debug>Windows>Call Stack)

    the function that appears like 10,000 times....is where your problem is :)






    Any and All code is provided only as a guide. - learning visual basic
    Friday, September 11, 2009 2:47 PM
  • Thank you guys very much for the insight. I am very busy now trying to run this app. I came back to say that I found a goofy mistake in that statement I posted. The error (invalid cast) was not noticeable because I enclosed the whole block in try/catch restraint and did not post Exception ex in parentheses. When I looked into details I saw that there was a hidden exception Incorrect cast because I typed double instead of the second long.

    I will see how the correction affects the run and will come back later, perahps at the end of the day to review every post and learn what you are saying.

    If the exception persists, I will say so as well.

    Many thanks, Bill and others as well.
    AlexB
    Friday, September 11, 2009 2:59 PM
  • It seems that was the cause. So, the lesson I am learning form this misfortune (provided the conclusion is confirmed by a much longer run) is that bad casting which sometimes does not even cause an exception (there are such circumstances) can accumulate somewhere and that memoy (stack) gets fed up at one point and throws an exception.
    AlexB
    Friday, September 11, 2009 3:56 PM
  • I've marked all contributors' posts as answers because they are definitely useful for me in other ways.

    Thanks.
    AlexB
    Friday, September 11, 2009 3:58 PM
  • It seems that was the cause. So, the lesson I am learning form this misfortune (provided the conclusion is confirmed by a much longer run) is that bad casting which sometimes does not even cause an exception (there are such circumstances) can accumulate somewhere and that memoy (stack) gets fed up at one point and throws an exception.
    AlexB

    Hey Alex...could you provide an example of such a bad cast? Thanks!


    William Wegerson (www.OmegaCoder.Com)
    Friday, September 11, 2009 7:46 PM
  • Let's say you are retrieving values from Sql Server,

                        foreach ( System.Data.Common.DbDataRecord sqlL1Record in rdr )
                        {
                            DataRow L1Row = Globals.dtSets.Tables[ tableIndex ].NewRow ( );
                            L1Row[ "Date" ] = ( DateTime )sqlL1Record[ "dateTimed" ];
                            L1Row[ "Bid" ] = ( double )sqlL1Record[ "bid" ];

    If I forget to cast the objects the values still be placed into the table but.... I don't know how to describe it.... but sooner or later there might be a trouble. I don't quite recall how I discovered it and what pointed toward the solution because of the hectic schedule and the need to take care of so many things but my impression is that because of such negligence exceptions like StackOverflow might eventually happen.
    AlexB
    Friday, September 11, 2009 11:11 PM
  • Gotcha...I worked on a system where we would annoint the targetted entity classes' properties with attributes describing how the data should be handled from the dataset. Basically the target column name and possibly the type of data (int/datetime/double). Then when it came time to extract the data a generic method would take the entity, reflect and enumerate the properties and thanks to the attribute extract the specific field from the dataset and cast/extract the proper data type to the object.

    Once setup the only failures occured during debug code creation time and where easily tracked thanks to the exception handling.  Plus one no longer had to extract data to properties of new tables/classes because the system did it all for you via the attributes and the generic method.

    Thanks for the clarification. :-)
    William Wegerson (www.OmegaCoder.Com)
    Saturday, September 12, 2009 2:52 AM
  • Thank you Bill. it is very valuable. Could you give a sample code of the attribute you've used? I will definitely implement something like this.
    AlexB
    Saturday, September 12, 2009 4:29 PM
  • I will try to get one to you tomorrow in the form of a blog post.


    William Wegerson (www.OmegaCoder.Com)
    Saturday, September 12, 2009 7:37 PM
  • Thank you Bill.
    AlexB
    Monday, September 14, 2009 2:49 PM