ID:1886190
 
Resolved
A new command-line option, -verbose, has been added to Dream Daemon. This will force runtime errors to print out full information (call stack, etc.) regardless of how many have occurred.
Applies to:Dream Daemon
Status: Resolved (508.1293)

This issue has been resolved.
Currently runtime errors are highly truncated after 20 errors and completely suppressed after 100. A single error in a ticker or any proc called with any frequency can quite easily reach 100 errors in a few minutes. Further errors from other sources become impossible to track, and it's especially frustrating because there's no way to disable this "convenience feature". This suppression made sense when all errors would get dumped to world.log and clog the file up, but now that we can handle errors more gracefully with world/Error(), there's no need to hide this information anymore.

If people actually want this silly feature, it can always be made an option in Daemon or possibly as a variable on the exception itself perhaps. At the very least, this suppression should only apply to identical runtime errors (same name, file, and line) so a ticker generating errors get suppressed but a mob doing an edge case error still gets displayed.
Why not just fix the error that happens frequently, and catch the others on a subsequent run?
Because ss13 is a big codebase and is all volunteer, so some errors can go left untouched for some time
That was the exact attitude I took when we had no control over how runtimes were handled. Dumping a ton of messages into world.log isn't great.

What I'm saying is that since we can now handle the errors properly, there's no fear of spamming world.log. If it's annoying, the programmer can handle that case themselves. There's no need to suppress the information anymore, and in fact hiding the information is actively harmful instead of a necessary evil.
In response to Lummox JR
Lummox JR wrote:
Why not just fix the error that happens frequently, and catch the others on a subsequent run?

I would absolutely love to, but when I can't test because my error quota was used up during initialization, it gets kinda tough to figure out what the error actually is.

You can always output the errors to a file to read later.
If errors appear during init, they should appear in world.log. If you run in Dream Seeker, then the errors should be available in the Options & Messages window.
This doesn't solve the issue.

tgstation has almost 300,000 lines of code.

$ ( find ./ -name '*.dm' -print0 | xargs -0 cat ) | wc -l
292010


Null reference runtimes are just a fact of life for us. We forbid rouge checking for null, considering that a bandaid fix to a bigger issue and a waste of cpu cycles. any fixes to null reference errors should be done by finding out why something is getting passed around that is null at the root, rather than adding if (!blah) return everywhere. This also means one bad line of code can end up triggering a null reference 10 items down in the stack.

A good chunk of our code is repetitive, in that it gets used by a lot of places, and the things triggering it will happen multiple times via a timer or repeative player action.

We hit the 100 runtime limit ALOT.

And we hit the 20 runtime limit for stack info almost every round.

This is mainly an issue because when we do bug fix drives where we get the volunteers to fix bugs, runtime bugs don't all get fixed because we can't actually see all of them, the ones we can see, mostly will not have stack info so we can't actually track them down. Most of the time, we get one bug in one of the run every soandso seconds timer loops triggering most of the runtimes, and within 15 minutes we've lost runtime logging.

Yes, we fix the bug, but then another shows up, and another, and another. Its just a fact of life for us, 300 thousand lines of code means every volunteer can't know every case of game state. So runtimes don't show up until production (if they do at all, because of absurd limits)

At the least, this needs to be a config option of some kind (maybe a world var, like loop_checks is)

You can always output the errors to a file to read later.
This fixes nothing. The limits still exists. I know because we already do that: (our runtime logs are public)

https://tgstation13.org/parsed-logs/sybil/runtimes/
https://tgstation13.org/parsed-logs/basil/runtimes/

At the least, this needs to be a config option of some kind

^
I do see what you mean. Maybe this is something I can get out for 508.1293.
also let us have stacktrace past a certain amount of runtimes too papa lummox
yeah it would be cool
papa lummox

We should start calling him papa bear.
Lummox JR resolved issue with message:
A new command-line option, -verbose, has been added to Dream Daemon. This will force runtime errors to print out full information (call stack, etc.) regardless of how many have occurred.
oh boy
cool
The fall/winter bugfixng freeze is upon us soon
First day this change is live on /tg/station's servers, a change is merged that creates a runtime in the atmos controller, a subsystem that runs twice a second.

https://tgstation13.org/parsed-logs/sybil/runtimes/ runtime-2015-07-17-condensed.txt
The following runtime has occured 286809 time(s).
Seems legit.
Thank god we have this so I can know just how badly I screwed up