Debugging stackoverflowexception when you can’t debug

General
1

Hi team.

I have an interesting challenge trying to debug a compiled application that only crashes sometimes.
I have my application set to run on startup and it’s fine around 80% of the time. The other times it failed with an ‘exception of stackoverflowexception was not handled….’

If I restart my application it’s fine
If I put a large delay at the start of my code it’s a bit hit and miss but not something I want to rely on.

I put a heap of system.debug messages in and auto launch debugview as well but this is proving inconclusive.

I’ve put try/catch statements around everything I can think of with no benefit

I obviously can’t run in the debugger because this issue only happens on startup (windows 10)

I have a feeling it’s network related but everything that uses sockets is wrapped in error handling.

Running out of ideas! Sorry for the long post. Love some inspiration Team!

2

Comment code out until the StackOverflow goes away. And yes, this method sucks.

3

Certainly does Beatrix. Especially when it comes back after you ‘find’ the problem…… no secret stack debugging that I could pull apart?

4

Do you have the unhandled exception handler? That might be worth a try.

Use logging with currentMethodname for each function and event of your startup. Then compare the logging of successful launches with those that get the exception.

5

Three ideas:

  • I would work on trying to simulate this state in the debugger, e.g. try running your app in the debugger with the ethernet cord unplugged, then try with ethernet plugged in but your cable modem disconnected, then try it after deleting the ethernet device from windows control panel, etc.
  • If you really can’t reproduce the “starting windows” state, then use tons of debug logging - add calls to
    System.DebugLog CurrentMethodName + " start"
    System.DebugLog CurrentMethodName + " about to begin foobar step 1"
    System.DebugLog CurrentMethodName + " foobar 1 complete"
    System.DebugLog CurrentMethodName + " exiting "
    in every method you think is involved.
  • use Application.UnhandledException to get the stack trace, so you can at least figure out which function is recursing. See sample code in Application — Xojo documentation
2 Likes
6

Thanks Mike,

I’ll give UnhandledException a shot. Also wondering if System.Debuglog is stored somewhere or if it needs to be read ‘live’ by DebugView or similar.

7

Create a small custom function to append to a local text file. e.g. App.Log(data as string)
The System.DebugLog requires an active debugger AFAICT.

1 Like
8

In builds this works just as well;

  • On windows you can read it using DBGview.exe you can download on the microsoft website
  • On MacoS you can read it using console.app
9

I often find it more practical to use Daniel’s method, because both DBGView and the Console can easily throw a lot of garbage (or things you’re not interested in). With the logging file, you write and read exactly what you want.
I’m talking about “complex” debugging only, of course.