[James Ross]

Csantucci, on 03 February 2019 - 11:50 PM, said:

I practically always disable the watchdog when I debug, because it jumps in often, especially if you are proceeding line-by-line. With SVN I had a patch, now it's a stash that I apply before starting debug. It contains the watchdog disable as well as a comment of this line within GameStateRunActivity.cs

               SystemInfo.WriteSystemDetails(Console.Out);

because - at least in my quite slow computer - that call may last many seconds.

The system details shouldn't take that long, but we can put an exception in if that is still necessary in the current version. Does it trigger the watchdog without any code changes, just running it from Visual Studio?

roeter, on 04 February 2019 - 06:39 AM, said:

You mean to say that developpers always run OR with debug attached?
I certainly don't - it's way too slow. Ofcourse I can't speak for other developpers but this seems a bit far fetched.

While developing code, I'm sure they'll run it with the debugger attached mostly. I know I do. Of course you'll also run it without, but given how I can barely tell it's running with the debugger (unless I have conditional breakpoints, now they are slow) I don't expect developers to run it without constantly.

roeter, on 04 February 2019 - 06:39 AM, said:

Anyway - even if it's so, it doesn't prevent developpers from switching it off. That's the problem with developpers - they know how to develop the program, so they also know how to alter things they don't like.

I want the watchdog being enabled to be the default for developers just like it is for users; I did not say anything about preventing developers turning stuff off if they were so inclined.

roeter, on 04 February 2019 - 06:39 AM, said:

The first things I do after getting 'official' code is to switch to 'console application' and disable the watchdog for debugging.

And I hope you realise this is at least partially why your code is what we're discussing here with regards the watchdog. Running with the watchdog during development greatly increases your chances of spotting these bugs before the code is "done". It obviously isn't perfect, but please at least try to understand what's going on here and help identify the precise issues.

[roeter]

Today, I had my first debug sessions using the 'official' version with VS2017.
The problem is complex so I needed a lot of stepping through long methods. After a certain time, the debugger started switching steps between the method I was testing and the watchdog code (the "while (true)" loop). It litteraly jumped between the code in TTTrain and Watchdog with each step (F10).
It is quite simply unworkable in this way, so I have put the !Debugger.isAttached back in again.

Regards,
Rob Roeterdink

[roeter]

The watchdog problem is more complex than I figured.
Today, I started my main timetable in the updated version with the proper watchdog setting and got this result.
 OpenRailsLog_190211.txt (113.99K)
Number of downloads: 235


As mentioned before, the pre-run for this timetable takes a very long time. During that time, the other threads have nothing yet to do.
It seems this causes the watchdog to time-out these threads. There can't be a loop in the render thread as the render thread is not yet active.

Regards,
Rob Roeterdink