Descriptive Problem Summary:
Viewing a profile that has been going on for a bit (about the latter half of one round, and the first half of another, 1 hourish from the client has consistently caused a server crash.
3 times now i go to open the profiler after I started a profiling job in it the last round, and the server crashes.
both server and client are on 509.1315r2
I don't have stack traces because the production servers have windows error reporting disabled so that the "dream deamon has crashed" dialog box doesn't keep DD running and the port open so that my tools can automate recovery of crashes.
ID:1990116
 Nov 28 2015, 3:56 pm
|
|||||||||||||
Resolved
| |||||||||||||
Even with error reporting off, the event viewer should have info I would expect. But you can also use WinDbg as your default debugger so it catches crashes.
| |
It seems we are running 508 still
| |
Faulting application name: dreamdaemon.exe, version: 5.0.509.1315, time stamp: 0x5656852d
Faulting module name: byondcore.dll, version: 5.0.509.1315, time stamp: 0x56563402 Exception code: 0xc0000005 Fault offset: 0x0012fc03 Faulting process id: 0x45c Faulting application start time: 0x01d12a2b71e7042c Faulting application path: c:\Program Files (x86)\BYOND\bin\dreamdaemon.exe Faulting module path: c:\Program Files (x86)\BYOND\bin\byondcore.dll Report Id: cdcf1abc-962a-11e5-80c0-00155d6ef20a Faulting package full name: Faulting package-relative application ID: All three have the same offset. And I have a bunch more random crashes I never reported (most of the time I never know about crashes, they recover so nicely now that I rarely hear about them), What versions would you be mildly interested in hearing about? I can pop them in a paste bin and send them to you. (obviously only ones with a byond module, since no stack trace.) | |
Probably anything from the last few releases would be helpful. That info you got for 1315 should be good enough, I think, for me to find where the profiler is hitting a snag.
| |
Happened when viewing profile from dd.
Crashed directly on hitting refresh. Seems to happen consistently if the profile survives a world.reboot() Because that was a pretty short round. | |
I found out profile info is not reset between reboots. Normally I'd want to carve out an exception for this so that restarting the same world wouldn't reset the profiler data, but it's much easier for now to simply clear it.
| |
Lummox JR resolved issue with message:
Profiler data was saved between reboots, causing crashes in some games, or when recompiling a game or switching to a new game. | |
can't you just do what you always do to know if it's the same world?
crc that bitch? =P Literally everything else already does this, it seems like a better solution then breaking long term profiling. | |
Thing is, not a lot is meant to persist between sessions. I'd have to add some stuff to handle the comparison in order to allow that. The fact that profiling didn't reset between sessions was an oversight.
| |
hmm...
I could see it resetting if you hit the stop button, but it's hard to profile round start unless you start it the round before. and it would be hard to profile round end if it resets right after. You see where I'm coming from? | |
Yeah, I see what you mean.
| |
This would all be things that could be solved in soft code if we had a way to access the profiler and list of profiled procs in soft code...
Something that would be super handy for automating profiles, and storing them in a way that included pop count so other code (a site based php script) could let you see aggregate profiles based on pop count ranges, split them up by commit hashes (something we store in game already) Oh man the things I could do if I could automate starting, stopping, and storing profiles. anywho i'm sure you'll figure something out. | |
I'm not sure what version we are running at this precise moment, I would have to ask pomf123.