ID:1500172
 
Resolved
Calling a proc using named arguments, if the proc didn't expect any, could cause a crash.
BYOND Version:504
Operating System:Windows 7 Pro 64-bit
Web Browser:Chrome 32.0.1700.107
Applies to:Dream Daemon
Status: Resolved (506.1239)

This issue has been resolved.
Descriptive Problem Summary:
Basically, if you use random crap in the arguments of a proc call, that the proc itself don't use, dream deamon will crash with no warning or runtime.
Now, if the proc DOES use the arguments, it won't crash.
By random crap I mean something like do_stuff(crash = "rip") when crash is not a variable itself.
Numbered Steps to Reproduce Problem:
Just use the code provided on this post to reproduce it, it's fairly simple.
Code Snippet (if applicable) to Reproduce Problem:
mob
verb/do_stuff()
var/obj/H = new /obj(src)
world << "object created"
sleep(20)
H.crashing(pete = 10)// just some random crap to crash


obj

obj/proc/crashing() //crash here
world << "we didn't crash" //this never happens
return


Expected Results:
to have a runtime or maybe a compile error? Crashes with no warning or logs ain't fun

Actual Results:
crash!

Does the problem occur:
Explained in the summary, when you use random crap in the arguments of a proc call. It always happen but the exception explained below.

When does the problem NOT occur?
Explained in the summary, when the arguments are actually used by the proc.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
I do not know.

Workarounds:
Fill your proc call arguments properly.


btw I think I'm using 504.1232 because I have my byond up to date and that's what the download page says that it's the lates version and I have no idea how to check my own version
You can check your version by going to Help | About... in any of the BYOND programs.

To test with older versions--that would be helpful because I don't think this is a new bug--follow these steps:

1) Go to http://www.byond.com/download/build and download the zip file from an older build, such as the last 500 build.
2) Open the folder where BYOND is installed; you'll see folders like bin, cfg, etc. Create a new dir called bin500.
3) Open up the zip you downloaded, and go to its byond/bin folder.
4) Copy everything from that part of the zip into the bin500 dir you just made.
5) While in bin500, double-click on dreammaker.exe and load up your test project. When you run it from there with Ctrl+R, it will run in version 500.

I can do some tests on this myself too, but those steps are good to remember if you ever need to do any testing with older builds.
I have not been able to verify any kind of DD crash with the code snippet you provided. (Did you test that code in its own project, or did you just post it as an example of what you're doing that's triggering the crash?) I have been able to see a proc crash, where the runtime error says there's a bad arg, but the game should keep running.

If DD itself is crashing, I'll need some crash details. Windows should give you the option of seeing some detailed info about the crash, and what I'll specifically need are the module (usually byondcore.dll, since most of the work is done there) and offset where the crash occurred.
I gave the code to other people, they crashed too.
Try spamming the button? In this case acts a bit weird, it doesn't seem to crash instantly, it's strange.
Small update, apparently it runtimes on linux instead of crashing

runtime error: bad arg name 'pete'
proc name: crashing (/obj/proc/crashing)
usr: Mloc (/mob)
src: the obj (/obj)
call stack:
the obj (/obj): crashing(null)
Mloc (/mob): do stuff()
Running on Windows 8 with BYOND 504.1234 throws this:
"Unhandled exception at 0x007AC289 (byondcore.dll) in dreamdaemon.exe: 0xC0000005: Access violation reading location 0x0000002A."

Running on Linux with BYOND 504.1232 doesn't crash, instead throws this runtime:

runtime error: bad arg name 'pete'
proc name: crashing (/obj/proc/crashing)
usr: Mloc (/mob)
src: the obj (/obj)
call stack:
the obj (/obj): crashing(null)
Mloc (/mob): do stuff()
The runtime error is what I see on Windows XP. I have not yet seen a crash.
please don't forget about this
I need more information. I have yet to see a crash on this, only ever runtime errors. If you can produce a test case that causes an actual crash, I'm very interested in fixing it.

At least the error is easily avoidable by not passing named arguments the proc doesn't have.
The provided code reliably produces a crash for me on my system. I don't know what else I can do.
pls
In response to Aranclanos
I tried this code and didn't manage to cause a crash.
You said it crashed for other people - perhaps it'd be helpful to know what version/windows/etc they are using.

I didn't manage to get it to crash with windows 7 64-bit BYOND 498.1163 but my buddy did with Windows 8.1 64-bit and BYOND 506.1238.

Edit:
So then I tried with 506.1238 and it crashed after 4 clicks. Note that it also didn't give a runtime error for the first 3 clicks on 506, but does for each on 498.
Crash log from event viewer:
Faulting application name: dreamdaemon.exe, version: 5.0.506.1238, time stamp: 0x531fc9e5
Faulting module name: byondcore.dll, version: 5.0.506.1238, time stamp: 0x531fc998
Exception code: 0xc0000005
Fault offset: 0x000d354d
Faulting process id: 0x194c
Faulting application start time: 0x01cf40cf3ca5012a
Faulting application path: Z:\Temp Junk\506.1238_byond\byond\bin\dreamdaemon.exe
Faulting module path: Z:\Temp Junk\506.1238_byond\byond\bin\byondcore.dll
Report Id: 8725f1fa-acc2-11e3-ba92-6c626daaacf3
There's a small sleep() in the verb, so it's possible that you clicked it three more times before the first one actually ran.
im dying
everyday until crash fixed
Pls <3
Does not crash on 504.1234, but after using the verb once future clicks do not make it to the debug message.
Crashes on 506.1238 if I click and wait for the sleep.
Running Windows 7 Professional 64-bit.
I was finally able to reproduce this bug and can work on a fix. (Correction: I can reproduce this in the release version, not in the debugger. This does make a fix quite a bit more difficult.) However since there is a very clear workaround, I don't understand the urgency. The problem is only being caused by broken code to begin with, which should have been fixed once it was noticed; if not for the crash, there'd still be a runtime error which is still undesirable. If the code had been fixed after making this report, there wouldn't be ongoing crashes.
It's hard to tell which bit of the code is causing the crash if someone does something seemingly innocent, like renaming a proc's arguments to make more sense.
Renaming a proc's args won't cause the issue. From what I see, the issue only happens when the called proc has no named args, but is being called with named args.

On Linux you should get a list of the last procs that were called, which should be enough to track down any strays.
Page: 1 2