Reproduction Steps
The easiest way to reproduce this is to index an RBXScriptSignal and then print it out as such
print{[game.Loaded] = true}
Expected Behavior
I’d imagine the memory location of the object (just like every other roblox object) would be hidden from users since it could possibly be exploited, since I dont see this being exploited outside of Studio, I haven’t tagged it as such
Actual Behavior
The memory location is leaked
Issue Area: Studio Issue Type: Other Impact: Low Frequency: Constantly
As far as I can tell, this is not the memory location of the RBXScriptSignal itself - rather the memory location of the EventInstance. Try printing this out multiple times - you’ll see different memory locations.
I can’t reproduce the print{[Vector3.new()] = true} behavior - for me, I get this:
Interesting, I was able to reproduce the Vector issue. Not sure if this is 100% of the time since I just tested from one place file both in Studio and test mode.
That’s intentional. Just printing out a table or a function or a raw userdata even without the expressive output does the same. Not sure why you tried with if and in – those are reserved keywords and are therefore not valid identifiers. That is not a bug.
Wouldn’t that invoke the __index metamethod? And thus returning a new event instance? I can’t confirm this, but does =rawequal(game.Loaded, game.Loaded) print false?
Thats actually really annoying, I was using event instances to hook events between scripts but I guess since Roblox gives each new script signal its own object, it doesn’t work
Honestly, I dont get why this is a thing, and honestly should be changed in Luau down the road.
The memory address “leaks” are most likely intentional. Roblox already readily exposes the addresses of tables and userdata* with a simple tostring, and the addresses of other objects are also easily exposed by firing remotes with said objects as table keys.
I’m experiencing this as well. I’m trying to create a sort of hierarchy system but it’s hard to keep track when there is no indication of what the instance is. Would be kinda cool if there was a sort of “hyperlink” thing that happens when you try to print an instance.
Memory addresses of objects are readily exposed just by the fact that they are objects loaded into memory.
Indexing an object, even normally, results in a need to load from memory into a register (assuming it is in a table/etc, only local variables stored in registers are exempt). This will not effect whether or not something can be exploited, I can assure you of that.
That being said, not sure if it printing like that is intended or not?
