Serverside Client Error Response

ID:2523482
 
Nov 17 2019, 12:20 pm
Not Feasible
Applies to:Dream Seeker
Status: Not Feasible
Implementing this feature is not possible now or in the foreseeable future
I've got an issue in some code I'm running whereby the server works fine, but the client crashes (repeatedly, with only questionable workarounds) when attempting to load objects. Looking into the Windows Event Log, the client is segfaulting when attempting to load that particular item's icon (I believe, since even popping up a window with the icon but not the item itself causes the same crash). The server is blissfully unaffected by this issue.

On to the feature:
Add a /client proc that accepts errors like these when Dream Seeker encounters an error and crashes. This could be used to log the location where the error was registered, what the server was doing when the error was sent, and possibly even relocate the client someplace else away from the error as defined in the game's implementation.

I'm not sufficiently familiar with how BYOND processes its errors, but any info that helps fix code that *looks* alright in DM is a step in the right direction.

Here's a possible implementation. signal2text would convert the code to the text version. signal2text(11) => "SIGSEGV"
/client/Crashed(signal)
    world << "[ckey] has crashed with [signal2text(signal)] at coordinates [mob.x],[mob.y]!"
    mob.Crashed(signal) //Assuming that the developer also added a similar proc to mob.


I'll make a bugreport once I'm sure it's an issue with BYOND and not just some edge case that abuses undefined behavior in ways that occasionally cause issues.
Nov 17 2019, 1:22 pm
Procs don't run on the client, and a crash is a crash--it isn't something you can catch with an error message. If you have a repeatable crash, please post a bug report with a test case that can produce the error reliably and I'll be happy to take a look.
Nov 17 2019, 1:22 pm
Lummox JR resolved issue (Not Feasible)
Nov 17 2019, 1:34 pm (Edited on Nov 17 2019, 1:41 pm)
Now hold on a moment. I'm not saying prevent the crash. I'm saying, in the event that the client crashes, add an interrupt handler to the client which briefly sends some debug information to the server before failing.

Edit: As for the current crash I'm seeing, it's reliably unreliable. It depends on a random generation element of the game and is observed once every twenty-five or so rounds. The whole point of this feature is to allow me to isolate it, either for repair in the game's code itself, a bug report with a contrived (but reproducible) instance, or both.
Nov 17 2019, 2:10 pm
The thing about a crash is that the client *can't* send any details. It's already crashed.
Nov 17 2019, 3:55 pm
As long as the connection is alive and accessible to the signal handler, it should be entirely possible to get, at the very least, the signal type across.

Whether or not it's possible to actually transmit client state information beyond that is up to the implementation.
Nov 18 2019, 11:14 am
In response to KFive
A crash means the application is no longer functioning. It's like asking a dead guy to tell you how he died. The best you can hope for is a witness or forensic science to tell the story.

A client can only send the server info about expected conditions that it's designed to catch.