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.
ID:2033406
 Feb 9 2016, 1:05 am
|
|||||||||||||
Resolved
| |||||||||||||
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. | |
- 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.