It seems that in some cases local uses of a member variable in a proc are "cached" and can return old values even after the member variable has been changed.
The circumstances under which this seems to happen are pretty specific.
It seems that the member variable (t2 in this case) needs to be nulled / changed by a proc (break_stuff() in this case) on t2 which gets called first. Then if a variable on t2 is accessed (accessing t2 itself does NOT lead to the issue) for the FIRST time and it is an argument to a proc (as opposed to being an argument to << or assigned to a var) then the access to this variable gets the value of the object that USED to be in the variable but no longer is (t2.name in this case).
This is a confusing explanation so please inspect the code snippet.
Numbered Steps to Reproduce Problem:
Compile code below and run main(). Observe output, consult Expected/Acutal section below.
Code Snippet (if applicable) to Reproduce Problem:
world.log << x
var/name = "test2"
t.t2 = null
var/datum/test2/t2 = new
t2.t = src
var/datum/test/test = new
break_stuff() sets t2 to null and print("[t2.name]") runtimes as null.name cannot be accessed.
Despite break_stuff() setting t2 to null its name is printed as "test2".
Then isnull(t2) prints 1 confirming that t2 is indeed null.
Does the problem occur:
Every time? Or how often?Every time
In other games?N/A
In other user accounts?N/A
On other computers?Yes
When does the problem NOT occur?
Using world.log<< instead of a proxy method makes the problem disappear.
Doing print("[t2.name]") twice makes the problem not appear on the second call.
Setting t2 to null through simpler mechanisms than this seems to also make the issue not happen usually.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
From a brief tst 513.1490 also has the issue, likely goes way back.
I have no idea.