Journey Bunny
basically a webhook for script errors
-- Nexii Malthus, summarizing what we need
You develop scripts for Secondlife. You start hearing people reporting that your scripts are crashing. Now what?
Unless it's a very reliable crash, you're kind of in unexplored territory. SL is vast, many unique and hard-to-reproduce situations could be happening. The crash log is seen by your end user, not by you. The developer cannot know how widespread the problem is, whether it's a bug in a SL Server update, whether it's an edge case in their own programming...
Possibly avenue to a solution:
An unmodified, compiled script has consistent bytecode, and if I understand it right, an internal asset id corresponding. The simulator knows when this item has crashed (and currently only generates a message to the owner on a message channel).
Perhaps a developer could "flag" scripts for logging "that script", or the set of scripts for a project that is in the wild and reporting problems. The developer could view (on the web? in the viewer?) a simple log, aggregating the crash reports from the currently-logged scripts, grid-wide for each flagged script. Perhaps some bit of information like the simulator version/memory use/event queue at time of crash. The simulator knows all sorts of things about what happened;
Any
log improves the current total black-box situation. Eg, "hearing that scripts are crashing on region restart? start logging now and see what comes in".
This would be a limited utility. The number of scripts we can flag and limit how many log entries each script holds would be small. This would not be a performance monitoring tool; it would be turned on when a problem is suspected, to capture what's happening "out there."
Acknowledged implications: Plenty of privacy concerns abound. To avoid adding new means of tracking users, gaining access to personalized data etc:
  • The developer should not be able to find out what specific region the script was in when it crashed
  • The developer should not be able to view the script's memory
  • The developer should not be able to view who was running the script
Might be useful:
  • What type of crash
  • list of events queued
  • simulator version number
  • region status
Anything else that could be useful without opening bad implications? Any other implications that need calling out?