1

My code calls a third party component ( which I don't have source code access to), unfortunately, StackOverflowException was thrown from the third party component, and when I look at the stack trace, it's all third party component calling itself.

I can't even tell which line of my code that calls into the offending third party method, because the stack trace is consisted of nothing but the same third party method calling itself, all over again.

How to make the VS2015 debugger to break at my source code when StackOverflowException is thrown from third party component? Is this possible at all?

I can always try step by step debugging, but my code is so messy that I prefer to do it at the last resort.

Edit: Note that this is different from the question-- C# catch a stack overflow exception. This is related to how to break at my code and not how to catch a StackOverflow Exception.

Graviton
  • 81,782
  • 146
  • 424
  • 602
  • have you tried step by step debugging? – DrNachtschatten May 26 '17 at 06:19
  • @DrNachtschatten, I can, but my code is so big and messy that this is my last resort – Graviton May 26 '17 at 06:21
  • 1
    Why not to use try-catch + Debugger.Break in the catch? – Leonid Malyshev May 26 '17 at 06:29
  • @LeonidMalyshev, not sure whether I know about this in detail, care to expand your comment into an answer? – Graviton May 26 '17 at 07:40
  • 2
    Possible duplicate of [C# catch a stack overflow exception](https://stackoverflow.com/questions/1599219/c-sharp-catch-a-stack-overflow-exception) – Jay May 26 '17 at 08:11
  • @LeonidMalyshev - You can't catch a Stackoverflow exception using a try/catch - see https://msdn.microsoft.com/en-us/library/system.stackoverflowexception(v=vs.110).aspx . Graviton - According to the same source, I'm pretty sure you can't break on a stack overflow exception as it kills your process by default. Maybe you can use AOP (something like PostSharp logging) to log every method called, and where it stops logging will be where your exception is occuring. Then you can step into code at that point, rather than wading though a whole mess of inherited code. – Jay May 26 '17 at 09:20
  • @Jay, I don't need to "break" on a Stackoverflow exception-- I just need the debugger to show my line-- instead of third party library's line when this exception is thrown by IL instruction – Graviton May 26 '17 at 09:32
  • @Graviton - Yup, I get that, what I'm trying to say is that if the SO exception has killed your process (which is what MSDN says it will do); your debugger can't break back in your code, because there is no process in a valid state to visualize. You can't even catch a stack trace if you do this in your own app - try it yourself `class Program { static void Main(string[] a) { X(); } static void X() { X(); } }` and look at the debugger when it shows what is wrong... there should be no stack trace information, so if this is happening in 3rd party code, the debugger *can't* get back to your code. – Jay May 26 '17 at 09:45
  • @Jay, what about the "Enable Just My Code" suggestion in the [answer](https://stackoverflow.com/a/44196671/3834) below? – Graviton May 26 '17 at 10:16
  • @Graviton Have you tried it? I have; I enabled 'just my code', and i can't make it stop in my code when referencing an assembly (which built in release without pdb files) that throws a SO exception. The process just dies and my debugger shows nothing useful (I just get `System.StackOverflowException was unhandled Message: An unhandled exception of type 'System.StackOverflowException' occurred in SoTest.exe`). That's why I suggested postsharp AOP/logging earlier, but hey - if it works for you then that is your answer! :) – Jay May 26 '17 at 10:32
  • @Jay, no, I haven't try it. I could have done that before I asked the question-- but the whole point of SO is to document these nuances so that they are helpful for other developers, don't you think so? :) – Graviton May 26 '17 at 10:45
  • @Jay, if it doesn't work, maybe you can comment on the answer and say that it doesn't work, this will help other developers too – Graviton May 26 '17 at 10:45

2 Answers2

1

So after a fairly length discussion (above) - My tuppence worth is that I don't think this is actually possible.

According to MSDN, a StackOverflowException will terminate your process...

Starting with the .NET Framework 2.0, you can’t catch a StackOverflowException object with a try/catch block, and the corresponding process is terminated by default.

If your process is terminated, you cannot then point the debugger back to your source code. that is because there is no reference. A simple example:

class Program 
{ 
   static void Main(string[] args) 
   { 
      Foo(); 
   } 

   static void Foo() 
   { 
      Foo(); 
   } 
}

The above program will go into an infinite loop and throw a Stackoverflow exception. You (should) get a message that your process is terminated, and the debugger will show no stack trace information.

That last part is important; if there is no stack trace information - you (or rather your debugger) cannot walk back up the stack to your code.

Building this same example (and making it public) in release mode with no PDB files and referencing it from a second console application mimics the OP's question - calling 3rd party code with no source that throws a SO exception.

When I do this, I see in my debugger no information other than System.StackOverflowException was unhandled Message: An unhandled exception of type 'System.StackOverflowException' occurred in SoTest.exe (and this is also the case if I enable 'Just my code') - the program subsequently terminates and I have no pointer as to where the process terminated.

I would recommend implementing AOP logging (I have used postsharp - and last time i checked was free - though this might not be the case anymore) to add logging to all your method boundararies in your inherited code, and then step from where the last line of logging occured to find the rogue call in the 3rd party assembly that is causing a SO exception.

Jay
  • 9,561
  • 7
  • 51
  • 72
0

Normally option inside Debugging->General->Enable Just My Code should do the trick. You should mark it and then debugger should stop inside your code instead of 3rd party library. However you need maybe to fulfil some more conditions like i.e. delete .pdb file.

Here some more details: Understanding Just My Code

EDIT:

Yes, Jay you are right sorry for misleading answer without checking. I checked it now on VS 2015 and I found interesting side-effect which could help you to find proper place in code.

After Exception window is shown place in code is marked by gray rectangle. It means if all windows with source code containing invocation of hanging component will be opened during debug session it should be possible to see where exception occurs.

enter image description here

Seems that VS cannot enter debug mode because of lack of stack, but just before hang correct line is marked.

Condition: Source file must be open. So if amount of files containing invocation of this "bad" external code is reasonable maybe this could help.

smartobelix
  • 748
  • 5
  • 16
  • I don't think this will work for a StackOverflow exception - please see my answer for the reason why. A StackOverflow exception is different to most other exceptions in that it will kill your process when it occurs, so you don't get a stack trace, and you cannot therefore stop in your code (as the debugger won't be able to walk the stack back up to your code, and it won't be running anymore). – Jay May 26 '17 at 11:06