Memory address of Roblox objects is leaked with table indexes

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


Turns out this affects all Roblox classes, not just RBXScriptSignal, I cant tell if this intentional or a bug, so I’ve reported it as such


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{[] = 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.


Sounds related to 481 and the class changes.


Not sure if I am behind, but isn’t native Vector3 still in beta? It was an opt-in beta feature, you may have opted into it


And as people have pointed out above - your results were different because you were probably opted into native Vector3 beta.

1 Like

This also happens for tables and functions, and doesn’t work with if, in, and more.

That’s a different test - I’m running print{[game.Loaded] = true}

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?

Yep - as far as I can tell, that’s exactly what’s going on.

I tried them solely because I was very curious.

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.

*User-created userdata

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?

This is a regression. The Expressive Output Window is not properly invoking tostring on userdatas. It used to do this, to my knowledge.