These forums are CLOSED. Please visit the new forums HERE
ll[S/G]etOject[Desc/Name] can hold 8kb? |
|
|
Psyke Phaeton
Psyke's Defense Systems
Join date: 12 Oct 2003
Posts: 197
|
11-03-2006 05:29
I was playing with llSetObjectName and llKey2Name expecting to only get about 63 bytes from llKey2Name but I noticed I got more. Testing further I managed to store 8034 bytes with llSetObjectDesc and 7955 bytes with llSetObjectName and retrieve both correctly.
NB: SL client and llSay will show both truncated but scripts can see all the data stored Did something change or has this secret stash of storage been kept secret. It wasn't mentioned in the Wiki's. This seems to be a good way to hack object to object comms with llKey2Name pulling data off another Object's (or its hidden child prim's) name from anywhere in the same sim. llSetObjectDesc looks like good storage too. Or am I just slow?  _____________________
 "Our goal is to have as little control as possible." -- Corey "Linden" Ondrejka, Vice President of Product Development, Linden Lab. 16th January 2006 |
|
Llauren Mandelbrot
Twenty-Four Weeks Old.
Join date: 26 Apr 2006
Posts: 665
|
Cool!
11-03-2006 07:25
Does this information survive being inventoried?
|
|
Archanox Underthorn
Registered User
Join date: 20 May 2003
Posts: 168
|
11-03-2006 07:32
I noticed this using ll(Set/Get)ObjectDesc() but after a while it seems the data would get truncated down to 255 like its supposed to be. Sometimes it would take a few days, not sure exactly when it happens, but eventually it would.
_____________________
Archatek
Home to some of the highest quality katanas and other blades available in SL. Co-creator of the Samurai Island Combat System, one of the best melee combat systems available, come check it out! ___________________ |
|
Llauren Mandelbrot
Twenty-Four Weeks Old.
Join date: 26 Apr 2006
Posts: 665
|
11-03-2006 07:38
I`m guessing that a sim state-save-and-restore is a likely candidate for when the information is lost.
Anyway, this sounds like a good place to cache expensive-to-calculate but replaceable information that isn`t likely to change often. Fetch the data, and only recalculate it if it isn`t there. |
|
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
|
11-03-2006 12:23
If this data truly does get lost on a simstate save/restore cycle or when sent through inventory, I have to wonder... does that mean they're overflowing a buffer? Did you ever manage to crash a sim this way?
|
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
11-03-2006 13:43
I was playing with llSetObjectName and llKey2Name expecting to only get about 63 bytes from llKey2Name but I noticed I got more. Testing further I managed to store 8034 bytes with llSetObjectDesc and 7955 bytes with llSetObjectName and retrieve both correctly. Years ago I posted a similar thread about using the object name for information transport (it might have been my first thread ever; think it's in the script library). Anyway, they fixed it soon after I posted it so it would properly chop the string down. The chopping happens when the sim gets around to it for both object names & descriptions. _____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey |
|
Zeera Xi
Real Join Date: Mid '05
Join date: 21 Sep 2006
Posts: 54
|
11-03-2006 18:23
Strife, noticed any pattern in that where the sim checks the object name and description to circumvent that problem?
_____________________
"RPG sim?
Why did I imagine a massive rocket propelled grenade, with people living on it." - Neil Robinson |
|
Psyke Phaeton
Psyke's Defense Systems
Join date: 12 Oct 2003
Posts: 197
|
11-03-2006 19:01
Suits my purposes perfectly I am pulling non-critical data, from one spot in a sim to another, that needs to last only 6 seconds.
_____________________
"Our goal is to have as little control as possible." -- Corey "Linden" Ondrejka, Vice President of Product Development, Linden Lab. 16th January 2006 |
|
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
|
11-04-2006 11:29
Wow. If you think about it, an object with an 8kb name could crash a fair number of scripts. Think about this: some script has a listen on channel n, and it uses over 8kb of memory already. You set your object up with an 8kb name, and have it say something on that channel. The listen event tries to allocate an 8kb variable for the name parameter, and bam, stack/heap collision. Anyone feel like testing this?
|
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
11-04-2006 11:56
Wow. If you think about it, an object with an 8kb name could crash a fair number of scripts. Think about this: some script has a listen on channel n, and it uses over 8kb of memory already. You set your object up with an 8kb name, and have it say something on that channel. The listen event tries to allocate an 8kb variable for the name parameter, and bam, stack/heap collision. Anyone feel like testing this? *evil grin* That was in my post a couple years ago  Through the manipulation of strings (adding them) i had managed to get 12k into the object name. I was developing a combat system at the time, i needed a way to move large quantities of data across the sim quickly. I believe part of what determines when it gets chopped is if a user tries to read it; either by mouse over or edit. _____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey |
|
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
|
11-05-2006 10:46
So, if there's a listen event sitting in my script's event queue, does the memory it takes up count toward my script's 16kb?
The announcement yesterday that llSay and such will soon have their length limits raised to 1023 is really awesome, and I definitely don't want to suggest that it may be a bad decision, but does it possibly make for an easier way to DoS a script with a listener, by stuffing 16 1023-length llSays at it? |
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
11-05-2006 12:21
So, if there's a listen event sitting in my script's event queue, does the memory it takes up count toward my script's 16kb? The announcement yesterday that llSay and such will soon have their length limits raised to 1023 is really awesome, and I definitely don't want to suggest that it may be a bad decision, but does it possibly make for an easier way to DoS a script with a listener, by stuffing 16 1023-length llSays at it? I don't actually know, if you can crash a script this way. Coming up with evil ideas always makes me laugh but doing them is another thing altogether (it isn't my thing). I never got around to testing it (if i remember properly, i had other fish to fry at that time in history. Like sim crashing prims; they were fun ).If i were designing LSL i wouldn't put event arguments in script memory. So only if the script interacted with the value would it run the risk of crashing (to interact with them, it would need to copy them to the stack; which is in script memory). After the event was finish, the space that the variable used could easily be deallocated. I wouldn't be surprised if this is how LSL works. It would be extra work to have things function differently. I have seen no indication that the event queue is stored in script memory. _____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey |
|
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
|
11-06-2006 10:53
I don't actually know, if you can crash a script this way. Coming up with evil ideas always makes me laugh but doing them is another thing altogether (it isn't my thing). I never got around to testing it (if i remember properly, i had other fish to fry at that time in history. Like sim crashing prims; they were fun ).Oh, don't get me wrong, I'm not evil I'm just thinking this kind of thing through on the theory that if I get to it first, maybe I can mitigate any risks that would come from bad people figuring it out.If i were designing LSL i wouldn't put event arguments in script memory. So only if the script interacted with the value would it run the risk of crashing (to interact with them, it would need to copy them to the stack; which is in script memory). After the event was finish, the space that the variable used could easily be deallocated. I wouldn't be surprised if this is how LSL works. It would be extra work to have things function differently. I have seen no indication that the event queue is stored in script memory. Hmm, well, that's a nice theory, but what about the fact that scripts have to be frequently packed up and moved around? I'm almost certain I've seen scripts trigger an event that had to have been queued before being packed up (a detach event) after the next rez. Maybe events are packed up separately, but if I were writing the system, I'd want to make it so that I could just yank around a 16kb chunk of memory all at once, yanno? So there are arguments either way. I'll have to test this when I get a chance. |
|
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
|
11-12-2006 17:13
Okay, it looks like you can't maliciously fill a script's memory this way. I had one object listening and sleeping 1 second each listen event and then saying its free memory, while another script was constantly llSay()ing on that channel. The memory usage never went up.
Unfortunately, I discovered that scripts in preview CAN'T chat 1023-length strings yet :( |
|
Yumi Murakami
DoIt!AttachTheEarOfACat!
Join date: 27 Sep 2005
Posts: 6,860
|
11-13-2006 04:28
So, if there's a listen event sitting in my script's event queue, does the memory it takes up count toward my script's 16kb? No it doesn't! I've experimented with storing 200k+ in a script by filling the event queue with looped-back link messages, each holding a 4k string. (Laggy, unfortunately, since in order to prevent the events from dequeuing it has to sit and wait in an infinite loop watching for a prim face to change colour.) The announcement yesterday that llSay and such will soon have their length limits raised to 1023 is really awesome, and I definitely don't want to suggest that it may be a bad decision, but does it possibly make for an easier way to DoS a script with a listener, by stuffing 16 1023-length llSays at it? You can't stuff the event queue, but as has been mentioned, you can make the script crash if it gets a 1k llSay and doesn't have 1k free when the event handler starts. |
|
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
|
11-13-2006 11:43
Wow, 200k in the event queue. If the object changes sims or is taken into inventory and rezzed or is otherwise packed up and moved around, is the event queue tossed?
|
|
Llauren Mandelbrot
Twenty-Four Weeks Old.
Join date: 26 Apr 2006
Posts: 665
|
11-13-2006 14:27
(Laggy, unfortunately, since in order to prevent the events from dequeuing it has to sit and wait in an infinite loop watching for a prim face to change colour.)Wouldn`t llSleep() have done the same thing, with less lag?
_____________________
|