Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
|
| 27 Apr 2014 12:12 PM |
Run this code in Lua 5.1:
getmetatable(newproxy(true)).__gc=print collectgarbage("collect") --> userdata: 1B1CD9A0
So the userdata was garbage-collected and the the metamethod was invoked. Let's try this in RBX.Lua:
getmetatable(newproxy(true)).__gc=print -- can't tell garbage collector to collect in RBX.Lua
But the metamethod never fires. Any idea of why this is? |
|
|
| Report Abuse |
|
|
Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
|
| 27 Apr 2014 12:20 PM |
chc4 answered my question:
There was a VERY old exploit with __gc which let it escape the Lua sandbox. The __gc metatable is fired by backend lua, not another thread, so it has an undefined context level. They just removed it instead of patching it, because who actually uses __gc? ;D |
|
|
| Report Abuse |
|
|
MrChubbs
|
  |
| Joined: 14 Oct 2010 |
| Total Posts: 4969 |
|
|
| 27 Apr 2014 12:23 PM |
| Remove it rather than implement a fix, poor practice at best. |
|
|
| Report Abuse |
|
|
Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
|
| 27 Apr 2014 12:28 PM |
| Actually it was a good idea. Fixes might still be vulnerable, so it's a waste of developer hours. And you shouldn't be using newproxy anyway, it's an undocumented Lua 5.1 feature. |
|
|
| Report Abuse |
|
|
MrChubbs
|
  |
| Joined: 14 Oct 2010 |
| Total Posts: 4969 |
|
|
| 27 Apr 2014 12:30 PM |
| It might patch the problem, but it's not good practice in general. Any method you expose to the public should needs to be kept that way and function consistently for the outside world, it's coding 101. |
|
|
| Report Abuse |
|
|
| |
|
MrChubbs
|
  |
| Joined: 14 Oct 2010 |
| Total Posts: 4969 |
|
|
| 27 Apr 2014 12:32 PM |
| Clearly I'm to tired for grammar, public needs* |
|
|
| Report Abuse |
|
|
| |
|
|
| 27 Apr 2014 12:34 PM |
>Clearly I'm to tired >to
yes i think you're right |
|
|
| Report Abuse |
|
|
Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
|
| 27 Apr 2014 12:34 PM |
| __gc is on the list of "probably <15 roblox users have ever used this in a game" |
|
|
| Report Abuse |
|
|
|
| 27 Apr 2014 12:36 PM |
| and 14 of those 15 weren't using it for the right reason (aka they try to exploit) |
|
|
| Report Abuse |
|
|
Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
| |
|
|
| 27 Apr 2014 03:31 PM |
| ...I'm one of the <15 I guess. |
|
|
| Report Abuse |
|
|
jobro13
|
  |
| Joined: 05 Aug 2009 |
| Total Posts: 2865 |
|
|
| 27 Apr 2014 04:10 PM |
newproxy is useless currently as we cannot attach a metatable to an existing userdata, forcing us to create an entirely new table which will clog up memory. I wanted to use userdatas for my framework but in the end I used tables for it. The only pity with using tables is that :__len() does not fire.
The ONLY reason why one should one could use new proxy is that :__len() fires. Another thing that is else is that type(newproxy()) returns "userdata" but I don't really see how that would be useful. Using proxies in a class system is bad practice due to creating identical tables which will clog the memory.
As noted, :__gc() does not fire. I once asked sim0nsays about this (if I remember correctly) and he indeed also said it is locked due to sandbox escaping and it will not be unlocked in the future. |
|
|
| Report Abuse |
|
|
stravant
|
  |
 |
| Joined: 22 Oct 2007 |
| Total Posts: 2893 |
|
|
| 28 Apr 2014 11:54 AM |
I'm convinced there is no legitimate reason to use __gc in Lua code on Roblox, which is why I didn't ask for it to be kept.
All of your "interesting" use case needs that fall in the area of __gc should be covered by Lua's weak-table features, __gc is not needed, and not intended to be used by Lua-side code anyways. |
|
|
| Report Abuse |
|
|
Maradar
|
  |
| Joined: 06 Mar 2012 |
| Total Posts: 4478 |
|
|
| 28 Apr 2014 12:04 PM |
@stravant i tl;dr half of the thread - could you explain in a few words what the main point of __gc is? |
|
|
| Report Abuse |
|
|
stravant
|
  |
 |
| Joined: 22 Oct 2007 |
| Total Posts: 2893 |
|
|
| 28 Apr 2014 12:10 PM |
The main point of __gc is so that C APIs like Roblox's can use it to free up C-side resources held by a Lua userdata when that userdata gets garbage collected.
You should almost never be writing code that does stuff like that on the Lua-side, and if you really want to, then you can use the weak-table functionality that Lua has to cover, at least the few cases I've found where I would want a GC like function. |
|
|
| Report Abuse |
|
|
Legend26
|
  |
| Joined: 08 Sep 2008 |
| Total Posts: 10586 |
|
|
| 28 Apr 2014 12:32 PM |
There is the fact that Lua's weak tables, in roblox at least, have a somewhat subtle, but irritating bug.
I remember not being able to figure out what conditions cause it. Something along the lines of adding a player/character to a weak table and then removing it from the table quickly with some delay. |
|
|
| Report Abuse |
|
|
|
| 28 Apr 2014 02:05 PM |
| Saying what the bug you encountered actually is might help... |
|
|
| Report Abuse |
|
|
digpoe
|
  |
| Joined: 02 Nov 2008 |
| Total Posts: 9092 |
|
|
| 28 Apr 2014 02:06 PM |
"I remember not"
Please. This isn't the Victorian era. No need to speak in rhyme. |
|
|
| Report Abuse |
|
|
Legend26
|
  |
| Joined: 08 Sep 2008 |
| Total Posts: 10586 |
|
|
| 28 Apr 2014 04:56 PM |
This model: http://www.roblox.com/Gateship-Puddle-Jumper-item?id=140581181
The current version has the lines 141 and 144 commented out in the main script because of the bug. In this case the bug manifests in this way: Two players are inside the jumper. One at the pilot seat turns the jumper on and opens the rear door, the other player stands just inside the jumper. Under normal usage, if the pilot cloaks and uncloaks the jumper and during the uncloak process the other player walks out of the jumper, the other player will re-appear. Unfortunately, using __mode, the player who walks out fails to re-appear. If you only have yourself to test this with, create a script that hooks onto a key and transports your character outside the jumper. Same effect as if there were two players.
Somehow the table is "forgetting" about the second player. Both I and Ganondude have gone over the code, and neither of us have found any other explanation or possible cause. |
|
|
| Report Abuse |
|
|