stack heap help!!!

[AlleyCat Tyles]

I am not asking an XPOSE question. I am using an XPOSE (version 4.0 ul) engine.  On restart, the engine will read the .MENUITEMS notecard into memory. On a script restart, the engine will read the .POSITIONS and .MENUITEMS notecards into memory. I am of course getting the dreaded stack heap collision due to the “script: ~loader”  being overloaded (out of memory, I believe) I understand fully that the size of the positions and menuitems consume memory and can cause the overload. But here is what is frustrating me:

I can load a menuitem notecard and everything works fine. I can take the same menuitem notecard. reduce the number of lines, restart, and get the stack heap collision. It is crashing after I reduce the size of the notecard and the memory used. Why would it work with a notecard using more memory and crash with a notecard using less memory. There are even times when it will crash on reloading and then on restart work fine with the same notecards.

My question is not on the XPOSE engine. My question is what external factors would cause this to happen? Keeping everything the same with the XPOSE engine, I get different results, so I am stumped what would be the causative factor.

[Qie Niangao]

One possibility that comes to mind is that the script reading the notecard might be hitting a bug with how it handles the shorter notecard. Perhaps, to get a consistent menu/response configuration it expects information or formatting that's missing in the notecards that get stack/heap errors. Of course the script should handle such conditions without spinning into some memory-exhausting cycle, so that's why that would be a bug with the script, not only with the notecard contents.

This comes to mind because I've seen it happen in a different animation engine that uses configuration notecards. I honestly don't remember the details now, but they probably wouldn't help much with this situation anyway. I guess I'd suggest chopping the notecard dramatically to a working condition and then adding gradually, keeping track of what specific addition crashes the engine, and then studying that isolated bit very carefully for any possible error.

[AlleyCat Tyles]

Let me add the following: Each time the stack heap error happens, the engine will automatically try a restart. If I just let it keep trying to restart over and over again, it has in a number of instances not crashed. It takes a number of restarts. So I tend to think it is an external factor.

[Phil Deakins]

The only external possibility I can imagine is that the total memory for all scripts in a sim is limited. I don't know if that's true or not - I'm just jusing my imagination. I imagine it's more likely that the limitation is on the box that holds mutiple sims. Either way, I think it's probable that the total memory allowed for all scripts is limited. So, if all scripts in a sim or server box is close to capacity, then it could happen that the last script that attempts to run has reduced memory for it, which would cause the stack-heap collisons because the stack and heap would meet sooner than normal. I'm stretching it, but it's the only possibility I can think of for an external (to the scripts themselves) problem. I doubt it's true though, because I feel sure that LL would have designed things so that, if there isn't enough memory left for a 64k or 16k script to use, then no memory would allocated to it. Qie would know whether or not it's a possibility. You could try taking it to another sim to see if you have the same problems there. The chances are that the sim you go to won't be in the same box. I don't think it would be successful but any port in a storm, eh?

 

@Qie NiangaoI'm not sure that your suggestion of drastically chopping the notecard, and adding bit by bit would work, because the problem isn't consistent. It's worth a try though. It could be that a certain type of line is always the culprit. It would take a number chops-rebuilds to determine though. I'm thinking more along the lines that a Restart in the xpose system isn't a full reset of the scripts, and that some variables are mounting up (being repeated), eventually causing the stack-heap collision.

Edited May 19, 2017 by Phil Deakins

[Qie Niangao]

Yeah, I don't see much chance that scripts are exhausting all available memory for the sim. Years ago, sims used to run out of RAM with too many scripts, but that would just cause paging into virtual memory -- and actually exhausting virtual memory would be quite a dire situation indeed.

That's a very good catch, though, about script "restart" maybe being something other than bare-bones script reset. I didn't even notice that "restart" was the term used, If that is a real distinction, then it's anybody's guess what XPOSE is doing with a "restart." Indeed, the more I re-read the original post, including its mention of another distinct "reload" operation (whatever that may be), the more I'm sensing that this question is purely XPOSE-specific, and that those of us who aren't XPOSE users have little hope of guessing what's going on.

[AlleyCat Tyles]

Ok, let me add on and respond to the postings. To be clearer, the engine stores the positions of pose balls in memory. This is unlike, say devPose, where the positions are written on a notecard and read when the pose is selected from the menu.

When properly operating, Xpose has both the menu and ball positions stored in memory. When using the menu it does not access any notecards. I think.

A restart using the Xpose menu results in the menu being deleted from memory and  reread from a notecard and stored into memory.

A reset of scripts (using edit or a SL viewer) will cause both the menu and the ball positions to be cleared from memory. Then the system restarts and reads into memory both the menu and pose ball positions.

Primarily, I am talking about restarting where I have problems. I have used reset in the belief that there was something accumulating in memory as one poster mentioned.

In response to the concern about a formatting error: The engine has very good debugging built right in. I have made formatting errors and it picks them right up and displays a warning message but does not lock up. Once it does finish loading, it displays the remaining memory for various scripts. It is the loader script that runs out of memory.

Yes, fully understand the logic of stripping out a large portion of the menu and adding it back one small piece at a time to diagnose the error. A bit time consuming. I have used the approach of carving out large portions of the menu and deleting pose ball positions which also take up memory. The creator says it should handle 200 poses. I have had it running in the 190’s. What prompted me to write today was I carved out a number of poses and it was fine last night. This morning it got the stack heap error and I have only 158 poses.

Yes, there is a limit on the number of poses, well aware of it. But today I am at 158 poses and getting this error which prompted me to think there was an external factor.

And thank you both for responding.

[Phil Deakins]

You could try contacting Miffy Fluffy (the xpose system creator). He may have come across the problem before, and know what the cause is.

Hmm. He doesn't show up in search, so maybe he's left SL, or maybe he logs in very infrequently. Perhaps he left SL due to most systems not now using poseballs, and he'd been doing his 2 systems, one after the other, for so long that he was simply fed up of it, decided not to bother updating his system, and moved on. That's total conjecture, of course. If you can get hold of him, he may already have the answer you're wanting.

Edited May 19, 2017 by Phil Deakins

[Phil Deakins]

2 hours ago, AlleyCat Tyles said:

When properly operating, Xpose has both the menu and ball positions stored in memory. When using the menu it does not access any notecards. I think.

A restart using the Xpose menu results in the menu being deleted from memory and  reread from a notecard and stored into memory.

That might be interesting. In his first system (MLP), a Restart started from scratch and loaded both the menus and the positions. Are you sure that the xpose system only loads the the menus? A Restart should load everything, because the positions in the notecard might have changed. I suspect that you just omitted to say that the positions are also loaded in a Restart.

You are correct that the notecards are no longer accessed after the system has booted up.

[ChinRey]

18 hours ago, Phil Deakins said:

The only external possibility I can imagine is that the total memory for all scripts in a sim is limited. I don't know if that's true or not - I'm just jusing my imagination. I imagine it's more likely that the limitation is on the box that holds mutiple sims. Either way, I think it's probable that the total memory allowed for all scripts is limited. So, if all scripts in a sim or server box is close to capacity, then it could happen that the last script that attempts to run has reduced memory for it, which would cause the stack-heap collisons because the stack and heap would meet sooner than normal.

As Qie said, that's rather unlikely since the server would have to run out not just of RAm but even of disk space before it happened. Besdies, it would not hit the same script over and over again.

 

13 hours ago, Phil Deakins said:

Hmm. He doesn't show up in search, so maybe he's left SL, or maybe he logs in very infrequently.

His/her MP store is empty too.

 

15 hours ago, AlleyCat Tyles said:

What prompted me to write today was I carved out a number of poses and it was fine last night. This morning it got the stack heap error and I have only 158 poses.

It looks like something is accumulating in memory. A wild guess here: does the script store position adjustments for each user and each animation?

[Phil Deakins]

21 minutes ago, ChinRey said:

As Qie said, that's rather unlikely since the server would have to run out not just of RAm but even of disk space before it happened. Besdies, it would not hit the same script over and over again.

Yes, I'd forgotten about the thrashing of old. Qie reminded me of it.

[ChinRey]

Has anybody looked at the actual code? I understand Xpose is no modify so the script can't be examined but the predecessor, MLP, is open source and it's unlikely Miffy Fluffy rewrote the core functionalities. Seems the only difference between the two is that xPose includes some rlv-like functions.

You could also ask in the xPose group. It's still there and has more than 250 members.

With all that being said, xPose is an eight years old update of a more than ten years old script system. So poseball based, lso rather than mono, a lot of scripts. Isn't there any more up-to-date alternatives?

[Phil Deakins]

I had a quick look in the MLP code yesterday, but nothing leapt out at me. A lot of xpose will be pretty much the same but I'm sure that much of it isn't. I never came across the problem described here with the MLP system, so I would think that examining it would probably be fruitless.

One solution is to get an up to date system and put all the animations into it. But perhaps the best immediate thing to do is what you suggested, ChinRey - ask in the xpose group. Some people there may have come across the problem and have the solution, or at least know that there is no solution.

Edited May 20, 2017 by Phil Deakins

[Phil Deakins]

1 hour ago, ChinRey said:

It looks like something is accumulating in memory. A wild guess here: does the script store position adjustments for each user and each animation?

That was my thought. Yes, the system does store position adjustments in memory. It has to. MLP replaces the old one, rather than add the new one, so I would assume that xpose does the same. Either way, position adjustments can't be the answer because the OP wasn't adjusting the positions, or he wouild have said so by now.

I suspect that a Restart does not start from scratch, and variables are being added to, but without being able to see the code, there's no way of knowing exactly what happens.

[Qie Niangao]

I suddenly realize that I'm unsure if this is for personal use, or if the target is a product for distribution. If the former, I'd strongly recommend migrating the notecards to AVsitter or any other well-supported engine to be found in one's own copiable furniture items. Or, to maybe keep with the existing notecards, just move back to MLP (if LearJeff got it up to handling this number of poses?).

If it's for a product... maybe then it's even more important to move to a current supported engine. If licensing costs are an issue, maybe nPose? No cost,  no poseballs, and nearly unlimited capacity because the notecards load on demand, but they're a huge pain to set up and manage. Or, I think there's probably still a number of sellers of MLP-based items.

Phil knows this whole area better than I do.

[Phil Deakins]

2 hours ago, Qie Niangao said:

Phil knows this whole area better than I do.

I don't think so. I used to sell stuff that used MLP, which I modifed to suit my stuff for 'scenes' (multiple animations), but I still have the original MLP system if the OP wants a copy. It only operates 2 avatars though, and the OP may want threesomes and more. After that, I wrote my own no-balls system which, theoretically, will operate more than two avatars but I've only ever used it with two, so there are bound to be bugs if used with more than two. I will have tested it with 3 avatars, but not extensively. You should just be able to add another copy of the user script and it will operate another user.

I never tried MLPV2, but I think it was used quite a lot, and it did accomodate more than 2 avatars. That was the whole point of it. It's free and I'm sure I have a copy if the OP wants it.

I'm amazed that a system would load positions from the notecard each time the animation changes. It must make changing anims slow. I'm sure I've got a copy of it too, but I never looked at it.

So, if the OP wants to change systems, I may be able to help with a free one (but not my 'No-balls' system. I may decide to start up again )

A consideration may be whether or not a different system uses mono. The MLP doesn't, and the MLPV2 (Lear) pre-dated mono when it was created, and was a modified MLP which didn't use mono, but it may have been updated. nPose also pre-dated mono when it was created but, since it's a no-balls system, which weren't around when it was created, it probably uses mono now.

Having said that, xpose pre-dated mono too, and it may never have used it. The copy I have certainly doesn't use it.

ETA: MLPV2 may be the reason why Miffy Fluffy seems to be absent. After all, the whole point of MLPV2 was the whole point of xpose - more than 2 avatars. Both were developments of Miffy's MLP, but MLPV2 was free, whereas Miffy was charging for xpose, and it wasn't cheap.

Edited May 20, 2017 by Phil Deakins

[Pussycat Catnap]

I got stack heap errors a lot when making a small HUDless AO script. All of them from memory issues.

This script: https://catnapkitty.wordpress.com/2017/04/09/low-memory-bento-animation-script-without-a-hud/

I fixed it with this:

testMemory(integer verbose)
{
    llScriptProfiler(PROFILE_SCRIPT_MEMORY);
    integer usedMemory = llGetUsedMemory();
    memoryLimit = usedMemory + 500; // a tiny buffer to please my sanity.
    llSetMemoryLimit(memoryLimit);
    
    if (verbose) {
        llOwnerSay("Limited Memory " + (string)llGetMemoryLimit() +
                   "\nUsed Memory " + (string)usedMemory +
                   "\nFree Memory " + (string)llGetFreeMemory());
        llOwnerSay("AnimationController script used at most " + (string)llGetSPMaxMemory() + " bytes of memory during Test.");
    }
    llScriptProfiler(PROFILE_NONE);
}

I run this function after most interractions, on rez. attach, animation change, and so on.

The key for my fix was find the actual memory being used: llGetUsedMemory();

And then to set my memory allocation ABOVE it. In the example above, I set it 500 above. For another script where I used this, I had to go to 1500.

When a script kicks off it allocates some amount of memory... and then if it actually uses more... it gets a stack heap error...

So I manually allocate an amount of memory, that I know is above what I will need, and then I re-allocate often.

The key is the re-allocation.

In my case I am polling my avatar every 2 seconds to see if my animation state has changed, if it has, I clear my current animation, re-allocate memory, and then set a new animation. This example is for a bento tail so 2 seconds was a fine delay...

When the script first starts, I set an initial memory allocation WAY ABOVE what I need, but then run this function at the end of my setup... so that I get a proper 'above by just enough' value.

Since doing this I have been 'stack heap error' free.

The 'verbose' thing in the above function was so that I could make a chat command that when called, calls this function in verbose mode to tell me what I'm using... that was how I found out I needed to put that buffer of 500 there... The actual use 'bounces around' a little bit... So I doubled the amount it was bouncing and then rounded off to a 'smooth to human eyes' number.

 

Edited May 20, 2017 by Pussycat Catnap

[Phil Deakins]

The problem here, P u s s y c a t, is that the OP doesn't have edit access to the xpose scripts - can't see the code and can't edit it.

Edited May 20, 2017 by Phil Deakins

[Pussycat Catnap]

Oh is the forum censoring my name?

[Phil Deakins]

It is - the first part. 'cat' is fine though

[AlleyCat Tyles]

Thank you all for your responses. I have now reached the conclusion that there is some external factor influencing or causing the stack heap error. After one occurrence of the error, I did nothing. XPOSE after an error, sits for a while then attempts a restart. Without changing anything, on the second attempt it worked fine. A different result without changing anything related to XPOSE. I suspect it is simple SL lag. In response to your comments above:

I know for sure that only the menu is reloaded on restart. Positions are perpetually maintained in memory. There is a specific button in the owner menu to dump position memory and cause both the positions and menu to be reloaded.

 

Yes, memory stores the positions. When you adjust a pose it will record the new position in memory. It overwrites the old position. Net effect should be that adjusting a position will not consume more memory. To be specific: On starting up, I get in chat something like “150 positions stored”. If I fix a number of positions and start up again, I will get “150 positions stored”. Adjusting positions does not increase the number stored.

 

My first approach was to use the XPOSE group in world. I did have a number of chats but no solutions which is why I tried the forums.

 

I am doing a project that is for 3 or 4 person poses. This is well within the parameters of the XPOSE engine I am using as confirmed by the documentation that goes with the engine.

 

This is totally for personal use. I have no intention of commercial use or to violate any terms of service.

 

Yes, XPOSE is an old engine but very tried and true. I am one of those funny people who like an old tugboat that goes 10 knots 100% of the time rather than a speedboat that goes 20 knots 50% of the time.

 

Thank you all for your help. I have finished my project for the most part and have just enough ~loader memory left over to avoid stack heap errors. But stay tuned, I love to tinker.

[Love Zhaoying]

I have seen problems lately where my script runs out of memory for some strange reason - but if I copy the code to a brand new script, it has lots of memory.  For me, what I am seeing is that somehow scripts are not truly freeing all of the memory after restart or recompile, and it gets worse as time goes on.  I have reproduced this twice lately.

Failing that, make sure all the scripts are checked MONO not "LSO"!

[AlleyCat Tyles]

9 minutes ago, Love Zhaoying said:

I have seen problems lately where my script runs out of memory for some strange reason - but if I copy the code to a brand new script, it has lots of memory.  For me, what I am seeing is that somehow scripts are not truly freeing all of the memory after restart or recompile, and it gets worse as time goes on.  I have reproduced this twice lately.

Failing that, make sure all the scripts are checked MONO not "LSO"!

The other thing I have done is take the mat back into inventory, wait for a while, then res it again on the floor. That appeared to work in some cases.

[Phil Deakins]

With the MLP system, the positions remained in memory even when the object is in the inventory, so, unless Miffy has changed that for the xpose system, in which case the object would boot up each time it is rezzed, what you're probably seeing is a coincidence, in that the next boot-up would have succeeded anyway.

Edited May 25, 2017 by Phil Deakins

[AlleyCat Tyles]

15 minutes ago, Phil Deakins said:

With the MLP system, the positions remained in memory even when the object is in the inventory, so, unless Miffy has changed that for the xpose system, in which case the object would boot up each time it is rezzed, what you're probably seeing is a coincidence, in that the next boot-up would have succeeded anyway.

Phil, I agree completely with what you said. I was addressing only Love's comment and thinking maybe taking it in and out of inventory would act as a memory cleaner.

[Love Zhaoying]

2 hours ago, AlleyCat Tyles said:

2 hours ago, Love Zhaoying said:

I have seen problems lately where my script runs out of memory for some strange reason - but if I copy the code to a brand new script, it has lots of memory.  For me, what I am seeing is that somehow scripts are not truly freeing all of the memory after restart or recompile, and it gets worse as time goes on.  I have reproduced this twice lately.

Failing that, make sure all the scripts are checked MONO not "LSO"!

The other thing I have done is take the mat back into inventory, wait for a while, then res it again on the floor. That appeared to work in some cases.

I need to try that with my script issue also and see if that helps. This is a script I am constantly working on, in a HUD.