ID:1848656
 
Not a bug
BYOND Version:507
Operating System:Windows 7 Pro
Web Browser:Firefox 37.0
Applies to:Dream Daemon
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
If you are running a proc with the src set to a turf, and then create a turf at the same location as ourselves in the middle of the proc things get weird. I've got a proc that has a short delay before finishing an action and the turf changing in the middle of it caused a runtime in a completely unrelated area.

Runtime was
runtime error: list index out of bounds
proc name: process (/datum/global_iterator/mecha_preserve_temp/process)
source file: mecha.dm,1693

and the thing it gave a completely wrong runtime on surrounded by asteriks.

/datum/global_iterator/mecha_preserve_temp  //normalizing cabin air temperature to 20 degrees celsium
delay = 20

process(var/obj/mecha/mecha)
if(mecha.cabin_air && mecha.cabin_air.volume > 0)
var/delta = mecha.cabin_air.temperature - T20C
******mecha.cabin_air.set_temperature(mecha.cabin_air.temperature = max(-10, min(10, round(delta/4,0.1))))*******
return
Lummox JR resolved issue (Not a bug)
This isn't actually a bug; the turf never ceases to exist unless the map actually shrinks. If you're changing turfs this is just something to be aware of.
However one issue does result from this lummox.

If a turf calls a proc or variable that existed on the old turf type after it was changed to a new turf in the meantime, it will runtime.

So anything with changeturf that involves a sleep has this inherent danger unless you are being very sane with your code.
I don't see that as a big concern. Anyone with a system that's changing turfs will typically not have those turfs call procs that sleep, and in those cases it also isn't common to change to a radically different type. Typically doesn't mean always of course; obviously you ran into this issue.

For me this is more of an issue of documentation. Maybe this needs to be better documented, because turfs are the only object in the DM language that can change their prototype at runtime without ceasing to exist. Stopping existing procs really wouldn't be feasible, though, as it would dramatically impact games that do a large amount of turf manipulation (SS13, for instance).
Well it isn't exactly a big concern as it can be relatively easily fixed when it comes up, but the reference guide says this on what sleep normally does for any other object:

"Also be aware, that a sleeping procedure whose src object gets deleted will automatically terminate when execution returns to it. This is to protect you against trying to access properties or procedures of a deleted (and therefore null) object. If you do not want the procedure to be terminated, you should set src to null."

Sleep has built in sanity for the case of an object being deleted but not for changeturf (which in many ways is functionally the same in that variables and procs would no longer exist from it).
The turf isn't being deleted; its type is changing.