Descriptive Problem Summary:
Dreamdaemon freezes up and becomes unresponsive shortly after clicking go (the game runs fine for several minutes). Program can be 'recovered' to unfreeze it but it locks up again shortly afterwards. Said problem has happened irregularly for the past two weeks, but has been minor. Since yesterday (with no code updates as far as I am aware) the server has crashed repeatedly every few minutes. I'm sorry I really can't provide any other clues other than internet explorer taking a long time to open local html files. I've suggested a virus scan, just waiting on that. We use a hosting service.
Half the time when it freezes up is when clicking on dreamdaemon's window. Whether that's what's causing a hang (it's not the only time it hangs indefinitely) or whether it's just that windows doesn't decide it's hanging until it fails to respond to me, I do not know.
"The program dreamdaemon.exe version 4.0.495.1136 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Problem Reports and Solutions control panel. Process ID: dec Start Time: 01cd59a8c62cc314 Termination Time: 2"
Binary data:
In Words
0000: 006E0055 006E006B 0077006F 0000006E
0008: 0000
In Bytes
0000: 55 00 6E 00 6B 00 6E 00 U.n.k.n.
0008: 6F 00 77 00 6E 00 00 00 o.w.n...
0010: 00 00 ..
That's all it gives me. Nothing particularly useful to go on.
Numbered Steps to Reproduce Problem:
1) Start server
2) All is fine... players begin to play
3) a matter of minutes later the server begins to hang indefinitely
Code Snippet (if applicable) to Reproduce Problem:
Haven't found the problem. Source code available if it would help.
Expected Results:
Some sort of error on the daemon log or possibly a crash message. (or not to crash obviously)
Actual Results:
Window just goes white and unresponsive...clicking the close (x) causes windows to do its usual "program not responding, recover, close, wait" thing.
Does the problem occur:
Every time? Or how often? Everytime
In other games? I will test this shortly after we've tried reverting some code.
In other user accounts? yes
On other computers? not to my knowledge. Only our server is affected
When does the problem NOT occur?
I wish I knew
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Problem has been occurring for 2 to 3 weeks. I upgraded to server to BYOND 495 (from 493) to see if it helped. There was no change. the problem did not appear immediately after any specific code update as far as I can tell.
Workarounds:
Haven't found any yet. I'm working on obtaining some alternate source to run to test if it's the server that's dying or the code.
| |||||||||||||
Lummox JR changed status to 'Unverified'
| |
Yes, sorry the information provided isn't very useful. There's quite literally nothing to go on.
Loop checks are on. We are compiled with debugging on so I may try disabling that for a bit. Anyway, we did get the server back up using the same code/settings (more by fluke than anything else). I can only assume it was a problem with the host. Maybe a service crashing or something along those lines that could cause daemon to freeze up? either that or something was changed without me knowing. I'll have to wait to find that one out though. I won't lie, I'm not great with computers so I wouldn't know where to start investigating further. Feel free to close this issue if it's of no use. Or if you know anything I can do to provide more detailed info just shout. EDIT: having spoke to a coder from another server using a similar codebase, they've been having the same issues and have very similar hardware to us. Whereas a server with a much faster setup using the same code as us doesn't really have this issue. I'm guessing TGstation code is just getting too ridiculously bloated *sigh*. Anyway, thanks for your help I guess the issue is resolved for now. We'll just have to continue to trim the fat. | |
That explains much. It'd be more accurate to say the code was passing bloated straight on into circus freak territory. We have some bugs open where people are running into problems just plain compiling that code.
| |
If you've turned off loop_checks, you need to turn that on. It should only be off when testing, never for the long term. With that in place, infinite loops should tend to work themselves out eventually by simply stopping the proc. There are exceptions of course, but most of the time when someone runs into this kind of thing it's because they have an infinite loop and they've disabled the means to stop it.