ID:2273631
 
BYOND Version:511
Operating System:Linux
Web Browser:Chrome 60.0.3112.72
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Using call()() on a object with a proc name string for the proc to call sometimes fails under linux on a object with a lot of procs. A proc typepath reference does not fail.

It's static per compile (and seemingly static per code change), it happens even if compiled under windows then ran on linux. Changing map files or adding/removing code comments has been known to trigger or untrigger the bug.

https://github.com/tgstation/tgstation/pull/29373/files

Changing comments makes no sense at all, because adding or removing comments would have zero impact on compilation. Files should be compiled in the same order consistently, and if the only change to their content is a comment, it will have no bearing on the final result. So there has to be more to it than that.

What this suggests to me though is that maybe something related to the old 64K limits is in play. Can you give me examples of some of the call() cases that have failed?
That PR I linked, is called during world init, it initializes all of our managed "global" variables (they sit in a datum) by calling a proc based off of a varname.

so something like
for (var/I in vars - excludelist) {call(src, "InitGlobal[I]")()}

Would either work for all, or work for none. (I think, actually, i'm not sure if it stops working or all of them, or only some of the call()()s)

But changing it to search thru subtypes of /datum/global_controller/proc and string matching against InitGlobal, and passing the direct proc reference as a type path.

(It's done this way so we can properly control exactly when "global" variables that contain initialize time references (like list or datums or proc calls) are initialized and not depend on undefined byond behavior, as well as let certain vars init before/after others without depending on undefined byond behavior)

I'll do some more testing to see, but because code changes can randomly make this bug show, it's hard to ever really know if something really triggered/detriggered the bug. The big thing i'll want to know, is if hascall() works correctly when the bug happens, and if text2path works correctly. Might narrow it down.

The comments thing could have also just been the issue deciding to randomly trigger, We first were told about this issue 3 months ago but we don't run linux byond servers so narrowing it down hasn't been easy.

Another code branch that does run linux servers figured this out.