ID:2394998
 
Resolved
The compiler was mangling the string tree in some cases, which could result in duplicate string IDs. This could literally cause a situation where "my string" did not equal "my string" at runtime. It also meant that associative list lookups could fail, because list["item"] might not match list["item"] due to the two item strings having different IDs.
BYOND Version:512.1445
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 68.0.3440.106
Applies to:Dream Maker
Status: Resolved (512.1448)

This issue has been resolved.
Alternative title: Two IDs one string

Descriptive Problem Summary:
Two identical strings don't evaluate as identical in some situations, presumably because of duplicate entries in the internal string table. Or something.

Code Snippet (if applicable) to Reproduce Problem:
Ok so I'm unable to reproduce this in a test case, but here's some code and debug output from the Goonstation SS13 codebase. Note for others reading this: Lummox and I went through this and he informed me to post this stuff.

Given the code (with debug output):
/datum/ehjax
var/list/allowedProcs = list("/proc/getBanApiFallback",
"/proc/getWorldMins",
"/datum/chui/proc/debug",
"/datum/chui/proc/close",
"/datum/chatOutput/proc/doneLoading",
"/datum/chatOutput/proc/ping",
"/datum/chatOutput/proc/handleContextMenu",
"/datum/chatOutput/proc/analyzeClientData"
)

proc
topic(type, href_list, client/C)
switch(type)
if ("main")
if (!href_list["proc"]) return 0
var/windowName
if (href_list["window"])
windowName = href_list["window"]
var/theProc = href_list["proc"]

//Generate the full proc path to check against whitelist
var/fullPath = ""
if (href_list["datum"])
fullPath = "/datum/[href_list["datum"]]"
fullPath += "/proc/[theProc]"

world.log << "EHJAX DEBUG: fullPath: [fullPath]"
world.log << "EHJAX DEBUG: allowedProcs: [json_encode(src.allowedProcs)]"

world.log << "EHJAX DEBUG: Ref of fullPath: \ref[fullPath]"
for (var/path in src.allowedProcs)
world.log << "EHJAX DEBUG: Ref of [path]: \ref[path]"

world.log << "EHJAX DEBUG: path is in allowed procs: [fullPath in src.allowedProcs]"
world.log << "EHJAX DEBUG: path is in allowed procs (find): [src.allowedProcs.Find(fullPath)]"

if (!(fullPath in src.allowedProcs))
CRASH("EHJAX: Attempt to call disallowed proc: [fullPath] by user: [C && C.key ? C.key : usr]")
return


And calling it with href_list values such that fullPath equals "/datum/chatOutput/proc/doneLoading", the following debug output is noted:
EHJAX DEBUG: fullPath: /datum/chatOutput/proc/doneLoading
EHJAX DEBUG: allowedProcs: ["/proc/getBanApiFallback","/proc/getWorldMins","/datum/chui/proc/debug","/datum/chui/proc/close","/datum/chatOutput/proc/doneLoading","/datum/chatOutput/proc/ping","/datum/chatOutput/proc/handleContextMenu","/datum/chatOutput/proc/analyzeClientData"]
EHJAX DEBUG: Ref of fullPath: [0x60165ea]
EHJAX DEBUG: Ref of /proc/getBanApiFallback: [0x600c998]
EHJAX DEBUG: Ref of /proc/getWorldMins: [0x600c999]
EHJAX DEBUG: Ref of /datum/chui/proc/debug: [0x600c99a]
EHJAX DEBUG: Ref of /datum/chui/proc/close: [0x600c99b]
EHJAX DEBUG: Ref of /datum/chatOutput/proc/doneLoading: [0x600c99c]
EHJAX DEBUG: Ref of /datum/chatOutput/proc/ping: [0x600b550]
EHJAX DEBUG: Ref of /datum/chatOutput/proc/handleContextMenu: [0x600c99d]
EHJAX DEBUG: Ref of /datum/chatOutput/proc/analyzeClientData: [0x600c99e]
EHJAX DEBUG: path is in allowed procs: 0
EHJAX DEBUG: path is in allowed procs (find): 0
[12:20:22] ehjax.dm,70: EHJAX: Attempt to call disallowed proc: /datum/chatOutput/proc/doneLoading by user: Wirewraith


Expected Results:
The string fullPath should be found in src.allowedProcs, and no CRASH() should occur.

Actual Results:
fullPath isn't found in allowedProcs, despite being the same string. As noted in the debug output above, the ref values of fullPath and the corresponding identical string in the list are in fact different ([0x60165ea] vs [0x600c99c]).

When does the problem NOT occur?
The issue occurs locally, but intermittently. Sometimes it works sometimes it doesn't. Presumably due to ghosts.

Notes:
Please do not judge my terrible code that probably should be refactored anyway.
Also, I have yet to test what version the issue was introduced in.
Lummox JR resolved issue with message:
The compiler was mangling the string tree in some cases, which could result in duplicate string IDs. This could literally cause a situation where "my string" did not equal "my string" at runtime. It also meant that associative list lookups could fail, because list["item"] might not match list["item"] due to the two item strings having different IDs.
This sounds like it could be the same issue as http://www.byond.com/forum/?post=2129715
In response to GinjaNinja32
It's not. The compiler change that caused this issue happened in a 512 beta.