ID:1938297
 
BYOND Version:509.1300
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 41.0
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Fault bucket , type 0
Event Name: BEX
Response: Not available
Cab Id: 0

Problem signature:
P1: dreamdaemon.exe
P2: 5.0.509.1300
P3: 55fc477c
P4: byondcore.dll
P5: 5.0.509.1300
P6: 55fc4676
P7: 0024ecd2
P8: c0000409
P9: 00000002
P10:

Please include the full build in the report. I know there's only one right now, but it's important for keeping track.

I'll also need to see where you set the client color, whether it was at runtime or compile-time. There's already a report for issues with this at compile-time, but if there's a runtime issue I want to see how that's triggered.
The compile-time issue goes for client/New() as well
In response to Lummox JR
Lummox JR wrote:
Please include the full build in the report. I know there's only one right now, but it's important for keeping track.

I'll also need to see where you set the client color, whether it was at runtime or compile-time. There's already a report for issues with this at compile-time, but if there's a runtime issue I want to see how that's triggered.

Was runtime and was set via a verb, it had worked fine on several different changes then just up and crashed when setting it back to normal
[1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1]
Can you show me the actual code involved?
In response to Pomf123
/client/verb/changeclientcolor()
set name = "change"
set category = "change"
var/choice = input("colors") as null|text
if(choice)
var/list/thing = text2list(choice, ",")
for(var/i = 1; i <= thing.len; i++)
thing[i] = text2num(thing[i])
color = thing
else
color = null
/proc/text2list(text, delimiter="\n")
var/delim_len = length(delimiter)
if(delim_len < 1) return list(text)
. = list()
var/last_found = 1
var/found
do
found = findtext(text, delimiter, last_found, 0)
. += copytext(text, last_found, found)
last_found = found + delim_len
while(found)
Hmm. Can you get better info from your event viewer than that? The list of parameters to the problem signature is useless, because apparently Microsoft has been playing around with that for some time and the subject is more or less Google-proof. I need to know the offset within byondcore.dll where the fault happened, and I think I can use that to diagnose the crash.
This is the only other entry i have regarding that crash,
Faulting application name: dreamdaemon.exe, version: 5.0.509.1300, time stamp: 0x55fc477c
Faulting module name: byondcore.dll, version: 5.0.509.1300, time stamp: 0x55fc4676
Exception code: 0xc0000409
Fault offset: 0x0024ecd2
Faulting process id: 0x1cac
Faulting application start time: 0x01d0f2f1925312af
Faulting application path: C:\Program Files (x86)\BYOND\bin\dreamdaemon.exe
Faulting module path: C:\Program Files (x86)\BYOND\bin\byondcore.dll
Report Id: f022191d-e5a8-4c96-8bbd-b89d9816b962
Faulting package full name:
Faulting package-relative application ID:
Thanks. That offset will help.
Hrm, rats. The crash offset isn't giving me enough to go on after all. If I could see further back in the stack it might help.
As I was unable to reproduce this, but I did find other issues, I recommend retesting in 509.1301. Chances are very good that the issue was solved as part of the other fixes.

If it crashes again, it'd be best if you can get more of a stack trace so I can see not only where it crashed but what the callers were. (Running a debugger can get that info, at least in terms of the offsets in byondcore.dll which should be all I need.)