.NET Forum / .NET Framework / New Users / September 2004
catching Runtime Stack Overflow Exception
|
|
Thread rating:  |
assaf - 30 Aug 2004 11:40 GMT hi all
i need to catch a Runtime Stack Overflow Exception.
how can i do this?
assaf
Kirby Turner - 30 Aug 2004 15:06 GMT Catch the StackOverflowException. Example:
try { // Do something } catch( StackOverflowException e ) { // Handle exception }
-KIRBY
>hi all > [quoted text clipped - 3 lines] > >assaf -- Kirby Turner, MCSD, MCAD www.whitepeaksoftware.com
assaf - 31 Aug 2004 10:49 GMT hi kirby.
i wrote exactly this code as u suggested. however, the exception is not cought. u can try it yoursef. just call recursively the same function.
assaf
> Catch the StackOverflowException. Example: > [quoted text clipped - 20 lines] > Kirby Turner, MCSD, MCAD > www.whitepeaksoftware.com David Levine - 01 Sep 2004 00:43 GMT Stack overflows are usually fatal so the app may exit before your catch handler gets called. Also, a blown stack might make it difficult, if not impossible, to unwind the faulted thread.
You might try running the code that blows the stack on a worker thread - the runtime might let the app live if its not the main thread that dies. In that case you could try hooking the unhandled exception handler.
Also, even if the app gets shutdown I believe finalizers will still run so you can still do some cleanup, but even that is problematic.
What are you trying to accomplish by catching this exception?
> hi all > [quoted text clipped - 3 lines] > > assaf Alvin Bruney [MVP] - 01 Sep 2004 05:37 GMT during stack overflow, finally blocks won't fire because there is no space left. catching that exception is usually a sign of poor design. a stack overflow should be allowed to take down the whole parade.
 Signature Regards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok
> Stack overflows are usually fatal so the app may exit before your catch > handler gets called. Also, a blown stack might make it difficult, if not [quoted text clipped - 18 lines] >> >> assaf David Levine - 01 Sep 2004 10:48 GMT > during stack overflow, finally blocks won't fire because there is no space > left. catching that exception is usually a sign of poor design. a stack > overflow should be allowed to take down the whole parade. I partially agree - it depends on a number of factors.
If the thread is the main app thread or in the default appdomain then I agree, but the situation is not clear for other threads/appdomains. A managed application ought to be able to setup an execution sandbox that hosts other managed applications (i.e. in a separate appdomain). If the sandbox crashes the main app should be able to survive it. An app that utilizes a plugin architecture has similar concerns - I would not want an ill-behaved plugin to crash my application. I ought to be able to run a plugin on a separate thread and only that thread should die if there is a stack overflow. How an application responds to a stack overflow is a policy decision that a hosting application should be able to make.
Alvin Bruney [MVP] - 01 Sep 2004 17:37 GMT hmmm, a few concerns come to mind (not thoroughly thought thru btw)
the stack overflow may or may not be coming from the plugin so catching all stack overflows is not guaranteed to fix the broken case
in the case of a plugin running in its own separate appdomain, the appdomain should isolate the hosting application from the catastrophic failure. but you shouldn't attempt to catch the stack exception. the app domain should be allowed to crash and the hosting application should simply log the failure. no clean up is needed because the crashed appdomain should be automatically unloaded.
in the case of the plugin running on a separate thread, it should be allowed to kill the hosting application as well. the failure will be restricted to the hosting app domain so it won't take down the webserver for instance (on IIS 6 for instance, lesser versions will die).
>How an application responds to a stack overflow is a policy > decision that a hosting application should be able to make. So i'm not really clear what you mean by policy.
 Signature Regards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok
>> during stack overflow, finally blocks won't fire because there is no >> space [quoted text clipped - 14 lines] > policy > decision that a hosting application should be able to make. David Levine - 02 Sep 2004 10:49 GMT > hmmm, a few concerns come to mind (not thoroughly thought thru btw) > > the stack overflow may or may not be coming from the plugin so catching > all stack overflows is not guaranteed to fix the broken case I am not suggesting catching all stack overflows - an internal fault in the host should crash it (a bug is a bug). However, IMO even there finally blocks on non-faulted threads should still run and currently they will not (I am not sure about finalizers - they usually run even when finally blocks do not). This makes it difficult, perhaps impossible, to write critical cleanup code that will behave correctly in all cases.
> in the case of a plugin running in its own separate appdomain, the > appdomain should isolate the hosting application from the catastrophic > failure. but you shouldn't attempt to catch the stack exception. the app > domain should be allowed to crash and the hosting application should simply > log the failure. no clean up is needed because the crashed appdomain should > be automatically unloaded. I agree, with the caveat that critical cleanup code on non-faulted threads should still get the opportunity to try to run. It may not be possible, but if code is critical it should still get an opportunity.
> in the case of the plugin running on a separate thread, it should be > allowed to kill the hosting application as well. the failure will be > restricted to the hosting app domain so it won't take down the webserver for > instance (on IIS 6 for instance, lesser versions will die). I agree, again with the same caveat.
> >How an application responds to a stack overflow is a policy > > decision that a hosting application should be able to make. > > So i'm not really clear what you mean by policy. All I mean is that the decision to crash the application should be one that the controlling host application should be allowed to make. This is similar to allowing the host application to determine what happens in the event of an unhandled exception - should the app swallow and ignore it? Or should the application be terminated?
assaf - 01 Sep 2004 14:36 GMT hi david
i am running on a 'worker' thread. with try-catch nevertheless, it crashes the app.
assaf
> Stack overflows are usually fatal so the app may exit before your catch > handler gets called. Also, a blown stack might make it difficult, if not [quoted text clipped - 16 lines] > > > > assaf David Levine - 02 Sep 2004 10:49 GMT > hi david > > i am running on a 'worker' thread. > with try-catch > nevertheless, it crashes the app. That answers the question, at least for this version of the runtime - it is fatal.
assaf - 02 Sep 2004 22:02 GMT hi David.
there must be a way to prevent the application from crashing. the stack-overflowing thread is just a background graphics analysis operation. my system should be able to recover from it.
here is its code that blows up the stack: RectangleF[] rects = this._Region..GetRegionScans(this._Matrix);
as u can see, it is caused by a Region containing too many rectangles. since a RectangleF is a struct, a value type, the entire array is allocated on the stack.
but this is something that if it happens, my application can simply ignore it! there is no way that this operation should bring down the entire application.
please help me.
assaf
> > hi david > > [quoted text clipped - 4 lines] > That answers the question, at least for this version of the runtime - it is > fatal. Jon Skeet [C# MVP] - 02 Sep 2004 21:27 GMT > there must be a way to prevent the application from crashing. > the stack-overflowing thread is just a background graphics analysis [quoted text clipped - 7 lines] > since a RectangleF is a struct, a value type, > the entire array is allocated on the stack. No it's not. Arrays themselves are *always* reference types. The values will be on the heap. It's more likely that GetRegionScans is recursing too deeply.
 Signature Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
assaf - 03 Sep 2004 08:09 GMT ok,
so what is the solution?
we are talking about a background analysis thread that if it fails, the app could do without it.
the crash only happens when the system is overwhelmed with user input. this is rare, but i would rather catch the exception then shut down unexpectedly.
please help me.
assaf
> > there must be a way to prevent the application from crashing. > > the stack-overflowing thread is just a background graphics analysis [quoted text clipped - 11 lines] > will be on the heap. It's more likely that GetRegionScans is recursing > too deeply. Jon Skeet [C# MVP] - 03 Sep 2004 09:37 GMT > so what is the solution? > [quoted text clipped - 6 lines] > > please help me. Well, can you post the code for GetRegionScans? It could be that you can either detect when the stack is going to overflow, or rewrite it so that it doesn't overflow in the first place.
 Signature Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
Alvin Bruney [MVP] - 03 Sep 2004 15:21 GMT yes, post that code. i fear you have some funky stuff going on inside that routine.
 Signature Regards, Alvin Bruney [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx] Got tidbits? Get it here... http://tinyurl.com/27cok
>> so what is the solution? >> [quoted text clipped - 10 lines] > can either detect when the stack is going to overflow, or rewrite it so > that it doesn't overflow in the first place. assaf - 03 Sep 2004 18:45 GMT hi all
here is the code. it is not so pretty. but really its nothing more then: put many rects into region. get rects array from region -> crash u can try it yourselves.
assaf
********************* my code ****************************
// background thread proc private void ProcessBuffersThreadProc() { while(true) { try { this.ProcessBuffers(); } catch(StackOverflowException ex) { WinForms.MessageBox.Show(ex.Message, this.ToString()); } } }
private void ProcessBuffers() { Region r = new Region(); r.MakeEmpty(); while(true) { if(this._Queue.Count == 0) { break; } object pBuff = this._Queue.Dequeue(); IntPtr ip = (IntPtr)pBuff; // queue contains buffers, each buffer is an array of rects // union add buff to region this.GetAndUnionRects(ip, re); // iterate all rects, union-add them each to our region } RectangleF[] rectArray; rectArray = this.GetRegionScans(r); // crashes in here // .... more fun stuff, that we never get to }
private void GetAndUnionRects(IntPtr ip, Region r) { for(int j = 0; j < this.gArray.ulRects; j++) { Rectangle rect = this.GetRect(this.gArray.Rects[j]); r.Union(rect); // this is where we add a rect into the region } }
private RectangleF[] GetRegionScans(Region re) { Matrix m = new Matrix(); m.Reset(); RectangleF[] rects = re.GetRegionScans(m); // this line throws the StackOverflowException!!! return rects; }
********************* my code ****************************
assaf
> > so what is the solution? > > [quoted text clipped - 10 lines] > can either detect when the stack is going to overflow, or rewrite it so > that it doesn't overflow in the first place. Robert Jordan - 03 Sep 2004 18:30 GMT hi,
> private RectangleF[] GetRegionScans(Region re) > { [quoted text clipped - 4 lines] > return rects; > } Are you kidding? :-) However, try this:
private RectangleF[] GetRegionScans(Region re) { Matrix m = new Matrix(); m.Reset(); // endless recursion condition if (re != this) { RectangleF[] rects = re.GetRegionScans(m); return rects; } else { return whatever but don't recurse! } }
bye Rob
assaf - 03 Sep 2004 20:25 GMT hi robert.
it is not recurssion! just the same function name. this system works very well 99.99% percent of the time. it only crashes in cases of abnormally high user input. in which case, i would like the exception to be caught and ignored!!!
assaf
> hi, > [quoted text clipped - 25 lines] > bye > Rob Jon Skeet [C# MVP] - 06 Sep 2004 07:35 GMT > here is the code. > it is not so pretty. > but really its nothing more then: > put many rects into region. > get rects array from region -> crash > u can try it yourselves. How on earth can we try it for ourselves when you haven't given the code for the method which is crashing?
Please post a short but complete program which demonstrates the problem.
See http://www.pobox.com/~skeet/csharp/complete.html for details of what I mean by that.
 Signature Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
assaf - 06 Sep 2004 09:48 GMT hi Jon
run this program. it crashes at the line: RectangleF [] rcf = r.GetRegionScans(m); // StackOverflowException i just need to catch it, nothing more.
assaf
using System; using System.Drawing; using System.Drawing.Drawing2D;
namespace Stack02 { class Class1 { static void Main() { try { Region r = new Region(); r.MakeEmpty();
for(int y = 0; y < 768; y += 2) { for(int x = 0; x < 1024; x += 2) { Rectangle rc = new Rectangle(x, y, 5, 5); r.Union(rc); } } Matrix m = new Matrix(); m.Reset(); RectangleF [] rcf = r.GetRegionScans(m); // StackOverflowException } catch(StackOverflowException ex) { Console.WriteLine(ex.Message); } } } }
> > here is the code. > > it is not so pretty. [quoted text clipped - 11 lines] > See http://www.pobox.com/~skeet/csharp/complete.html for details of > what I mean by that. Jon Skeet [C# MVP] - 06 Sep 2004 17:30 GMT > run this program. > it crashes at the line: > RectangleF [] rcf = r.GetRegionScans(m); // StackOverflowException Right, thanks for the test case.
> i just need to catch it, nothing more. I think you really will find this hard to do robustly, to be honest.
Your best bet may end up being to rewrite the method yourself, if possible, and make sure it doesn't recurse internally. Alternatively, make sure you never have regions with that many rectangles - split them and then reunite them later.
Sorry not to have better news :(
 Signature Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
assaf - 07 Sep 2004 09:22 GMT ok. tnx
assaf
> > run this program. > > it crashes at the line: [quoted text clipped - 12 lines] > > Sorry not to have better news :( David Levine - 03 Sep 2004 11:15 GMT A stack overflow is obviously a fatal condition, so your only option is to avoid overflowing the stack.
As Jon said, post the code. You state that this only happens when the system is overwhelmed with user input - what do you mean by this?
> ok, > [quoted text clipped - 10 lines] > > assaf assaf - 03 Sep 2004 17:58 GMT hi david.
the user through interaction with the application causes rectangles to be added to the region. so if the user interacts a lot, many rectangles will be added to the region.
assaf
> A stack overflow is obviously a fatal condition, so your only option is to > avoid overflowing the stack. [quoted text clipped - 16 lines] > > > > assaf Robert Jordan - 03 Sep 2004 11:44 GMT > ok, > [quoted text clipped - 8 lines] > > please help me. *Every* recursive algorithm can be rewritten using a stack. A good starting point is "Algorithms in <insert you favorite language>" by Robert Sedgewick.
bye Rob
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|