I have a StackOverflowException which is occurring deep inside the LINQ DataContext upon a call to SubmitChanges. After a lot of time wasted trying to pinpoint where the overflow is occurring, I can't seem to figure it out.
How can I see what the stack looked like just before the stack overflow is shown?
You cannot catch StackOverflowException unless it's thrown by the user code. (more info)
In visual studio, from the "Debug" menu, choose "New Breakpoint > Break at Function..."
In the "Function" field of the "New Breakpoint" dialog, enter StackOverflowException.StackOverflowException
Run your program in the debugger. Once you get the stack overflow, the debugger will stop at your breakpoint.
Related
While debugging in ASP.NET Core w/ VS 2019, when I have break on exceptions turned on 🟢, I break on the throwing, which is what I want 👍, but then I have to continue, F5 through each pop of the stack 🔁.
how do I say "CONTINUE out of this request & let the exception bubble up to the top w/o breaking"? is that an option in VS?
As the ASP.NET Core app is a long-running process, VS has no way of knowing where & when a request starts and ends. You can disable all breakpoints, hit F5, then re-enable them for the next request.
Use the top menu: Debug > Disable All Breakpoints
Use Breakpoints panel
You always can set a hotkey to speed up this workflow
I do believe that what you're seeing is the exception being rethrown on every async stack frame. You could confirm this if the exception dialog says that you can suppress the exception when thrown from System.Private.CoreLib.dll assembly, even though it was originally thrown in your code.
If you disable Just My Code, you should see that the exception is thrown from ExceptionDispatchInfo, which is the type used to rethrow exceptions with their original call stack in async/await. This is also what causes these exceptions to be thrown from System.Private.CoreLib.dll.
The only way I have found to improve this is to not break when the exception is thrown from System, either by using exception filter with module parameter, or in exception dialog > Exception Settings. This is only valid for exceptions that you never encounter from System.Private.CoreLib.dll. I am also not sure how this would work for Just My Code and external libraries as an exception might reach your code only after redispatch from async/await machinery.
With that in mind, you'll often just have to F5 all the way or rely more on breakpoints instead of exceptions for debugging.
Alternatively, as hinted in the other answer, you could disable exceptions until the request completes and re-enable them.
When I testing my code with OCUnit, it makes exception log and makes it fail, but never stop when the exception raises. Even the breakpoint doesn't work.
I want to track the stack and see the state at the time of exception, but debugger doesn't pop up. How can I debug test code like regular code?
Set an exception breakpoint on the project.
Go to the Breakpoint tab on the left pane of XCode. It looks like an arrow pointing Right.
Then at the bottom of that screen click the + and Add Exception Breakpoint...
My vs2010 shows this message when an exception is thrown:
How can I configure the debugger to show exceptions like this instead:
Thanks!
Big difference between the two. You'll only see the first one when you explicitly configure the debugger to stop when an exception is thrown. You do so with Debug + Exceptions, Thrown checkbox. You don't often use this, really only when your code contains too many catch statements that swallow exceptions inappropriately and making the code misbehave. It also has a knack for showing exceptions in code you didn't write. Click the Break button to allow the debugger to show you the details.
You'll only get the second screenshot when an exception is thrown and there is no catch block to catch it, making it an unhandled exception. That's a fatal error, the program cannot continue. The debugger stops to show you the problem, it is otherwise the end of the debugging session. Without a debugger your program will crash. This is the 'good' kind, you get it by omitting try/catch blocks so your program terminates when something unexpected happens. You will want to write an event handler for the AppDomain.CurrentDomain.UnhandledException event so the user at least has an idea what went wrong. And you for that matter.
I want to view the call stack when a stackoverflow exception is thrown. (i.e. I want to pin point what recursive call is causing the stack overflow).
The call stack is cleared and all that I can see is "External Code".
Edit I followed Chris Schmich's advice (post below), now I have a call stack like below, this is just a plain console app that I'm writing, notice that the is no mention of Main() in the screen shot:
Edit2: I followed Chris Schmich's advice about view the different threads call stacks, however I still can't seem to view my console app's call stack, here's what I can see:
The [External Code] frame you see is because of the debugger's Just My Code feature. The debugger is hiding stack frames from you because they are not in your code. Some details about JMC can be found in this blog post.
You can disable Just My Code by doing the following:
Debug » Options and Settings... » uncheck "Enable Just My Code (Managed only)" » click OK
You should now be able to see all of the stack frames.
For an example of JMC, when I step into a simple C# console app with JMC enabled, I see only the code in my solution...
...and with JMC disabled, I see Framework code as well...
Check this, Loading Symbols paragraph
Loading Symbols
They are *.pdb files, and you need to download them from microsoft so you can be able to see external code.
I have a problem wherein I get an AmbiguousMatchException in some of the samples from the Silverlight.FX samples.
The TaskList.aspx sample for example demonstrates this problem when I run Start Debugging the exception gets hit on line 202 in ListView.cs
FrameworkElement uiItem = itemTemplate.LoadContent() as FrameworkElement;
Except this problem doesn't show up when I Start Without Debugging. If I am debugging it will not succeed and create an item. But Without debugging it will.
Any ideas?
I would guess that the exception is being caught some where up the stack and you don't see it without the debugger being attached. Under Debug>Exceptions there are options for changing the way exceptions are handled when running under debug.