ID:2033406
 
Resolved
json_encode() sometimes decreased the refcount of random values (junk data), potentially causing a crash.
BYOND Version:510.1322
Operating System:Windows Server 2012 rc2
Web Browser:Chrome 48.0.2564.103
Applies to:Dream Daemon
Status: Resolved (510.1338)

This issue has been resolved.
Faulting application name: dreamdaemon.exe, version: 5.0.510.1322, time stamp: 0x56afd430
Faulting module name: byondcore.dll, version: 5.0.510.1322, time stamp: 0x56afd331
Exception code: 0xc0000005
Fault offset: 0x000a60d3
Faulting process id: 0x500
Faulting application start time: 0x01d1622b168a9ec7
Faulting application path: c:\Program Files (x86)\BYOND\bin\dreamdaemon.exe
Faulting module path: c:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: fb2fecd4-cf02-11e5-80c7-00155d6ef20f
Faulting package full name:
Faulting package-relative application ID:


We had this crash two times, one on each of our servers, i don't think it's the same as the other minimap related crash because this one happens mid round, and it has a wildly different offset.
I believe this crash is in DecRefCount() for an internal object. The object types that this encompasses presently are:

- Zip files
- Internal /icon structures
- MySQL connections
- MySQL queries
- Info from .dms files
- SQLite database reference
- SQLite query reference
- Regex

So it's one of those that's in play. The decref failing would tend to point to some type of corruption. Personally though, I've never cared for how this particular var type is managed and I might make it a project to abstract it out a little bit so these cases are harder to corrupt.
alright, next time it happens i'll do some digging to see if i can figure out what was going on before it happened. most of those trigger some kind of log entry before happening, be it the raw client/topic() logs, or something to that effect.
Game log:
TOPIC: "status", from:198.167.140.23, master:, key: (world topic: Status. nothing special)

client/topic log:
03:29 Pointlesswaste3 (usr:Reed Franks) || /datum/tgui src=%5B0x210104de%5D&action=eject (this action would involve moving an atom (obj) from being inside an obj to being inside a mob and added to that mob's screen. It also uses regex and json to send a reply back to the window that triggered the topic)


Edit: This has apparently been happening multiple times a day, but nobody ever tells me now that the watch dog restarts everything before clients even auto-reconnect. It's either this crash or the crash around minimap icons leaking and triggering a OOM crash.
Do you happen to have code from that spot, and maybe an example of the kind of data it would send back?
The design of the data being sent back is rather common to all /datum/tgui windows (there are a lot of them) it sends data back to all active windows about every 10 ds (it may get delayed a bit during lag and then fire up to 25% faster to make up missed ticks once the lag dies down).

How ever, looking at things, it doesn't seem like it actually uses regex, i must have mis-remembered.

topic handler: https://github.com/tgstation/-tg-station/blob/ b9c79680b92f058e2dda3d57e2265f6e7a4f3f3f/code/modules/tgui/ tgui.dm#L262

Data pusher: https://github.com/tgstation/-tg-station/blob/ b9c79680b92f058e2dda3d57e2265f6e7a4f3f3f/code/modules/tgui/ tgui.dm#L315

The data would have mainly came from https://github.com/tgstation/-tg-station/blob/ ed2e48cd350bb91abca5b59c1ea1852967953a21/code/modules/ reagents/chemistry/machinery/chem_dispenser.dm#L83

This wasn't too long after round start, and there are a lot of topics going back and forth at the start of the round as the crew starts using their department's equipment and doing their normal shift start routine. so this may be a red herring
Lummox JR resolved issue with message:
json_encode() sometimes decreased the refcount of random values (junk data), potentially causing a crash.