Jump to content

Dataserver hangs, but no hint of this in Wiki...


Domitan Redenblack
 Share

You are about to reply to a thread that has been inactive for 4616 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

That should do it, so my guess is that you are looking at the wrong problem.  Are you sure that your dataserver event is behaving properly when it senses an EOF?  You might be getting an overflow because it keeps reading line after line after line, well past the end of the data on your card.

Link to comment
Share on other sites


Rolig Loon wrote: That should do it, so my guess is that you are looking at the wrong problem.  Are you sure that your dataserver event is behaving properly when it senses an EOF?  You might be getting an overflow because it keeps reading line after line after line, well past the end of the data on your card.

I do an llGetFreeMemory( ); after every line read from the notecard. And when I do the myList = [ ]; the memory is not freed up.

Link to comment
Share on other sites


Domitan Redenblack wrote:

I do an llGetFreeMemory( ); after every line read from the notecard. And when I do the myList = [ ]; the memory is not freed up.

llGetFreeMemory never shows when variables are cleared or reset.

It is just a mark that show how high you have been in memory usage.

It is not reset until the script is reset.

The stack of pending events is limited to 64

Could that be a problem?

Link to comment
Share on other sites

1. EOF is always seen, except when the script crashes before EOF due to out-of-memory.

2. I have two lists in use; I fill up myNewList with lines from the desired notecard while preserving myList in case the user decides not to run the new notecard.

3. If the user declines to run the new notecard, I continue where we left off with the current notecard lines.

4. if the user accepts to run the new notecard, I set

myList = [ ];
myList = myNewList;
myNewList = [ ];

I don't see a way to be able to debug this without forcing garbage collection...

 

Question:

If I build myList, then build another list myOtherList, then load myNewList .... Will I *ever* be able to recover the memory taken in the original build of myList? Or does myOtherList block the heap and lock up the memory taken by the original myList ?

 

Link to comment
Share on other sites

Okay I see what is going on now. Due to the non-garbage collection, I do not see the memory freed, and when I load the next notecard, I have TWO notecards in memory when that is done, before I wipe the myNewList.

In some cases, the two biggest notecards loaded in succession are bigger than the (only) 25K I seem to start with each time (after Reset Scripts).

So, I can either shrink my scripts to start with more, or use a separate script to load in the new notecard... Does that sound like a good idea?

I suppose if things get Fat, then I can keep the current notecard in one script, and have it serve data to the main script, plus have a 3rd script which loads new notecards.

This only works if I get 64K of mono each time, yes?

Thanks

 

 

Link to comment
Share on other sites

You won't see memory freed using llGetFreeMemory().  As mentioned above, it only reports a high water mark (unless they've changed that recently).  So, forget about garbage collection; the results of llGetFreeMemory() have nothing to do with that.

Using multiple scripts is one solution.  Might be the best way.

But first, make sure you're using the most efficient way to append to a list for Mono.  When I originally tested mono memory usage, there was no apparent penalty for doing it the simple way, e.g.:

myList += item;

However, that was before they checked memory usage for every function call.  Now that they do that, the code above takes twice the space for myList plus the space for item.  I don't know the current best incantation for adding an item to a list in Mono, but it's on the wiki somewhere.  If you're doing the simple thing, you'll benefit a lot by using the optimized but illegible version.

 

Link to comment
Share on other sites

best practice for MONO appears to be "bite the bullet"... LSO you can still get away with the trick of wiping the list first.

for MONO LLGetFreeMemory will subside, but only after garbage collection, which happens completely out of our control. I don't know of any stats on how often it occurs, but anecdotally, it doesn't seem to happen during user functions at all, and possibly not during event code. it does seem to happen frequently during state change.

Link to comment
Share on other sites

Thanks again for updating me, Void!  Are you sure there's no way to avoid the double-space penalty in mono?  I remember reading a wiki entry that went into great detail about the best way for LSL vs Mono, with a few other variables as well.  Perhaps things changed since then.

I'm sure I never noticed seeing freemem go up since starting to work with mono, but since I believed it was still a high-water mark it might have happened and I missed it.

BTW, something changed behavior in Mono in the last month or so.  I have a product "Spin the Bottle" which has a master script that uses a hacked up MLPV2 in a child prim sort of like a marionette -- it's rather clever, and I do mean that in the pejorative sense.  It had worked without customer issues quite robustly for many months, but now it sometimes doesn't initialize properly.  The init involves interprim link messages and sometimes one is lost, probably due to a state change.    Any idea if anything significant changed in this area lately, or in the order of processing different kinds of events?  If that's not fuzzy enough for ya, we can make it even blurrier: just squint really hard.  ;-)

Link to comment
Share on other sites

I know the old LSO trick for memory conservation doesn't work in MONO... if someone found a new one for MONO I hadn't heard it (but I'm not as hooked in as I used to be)

the only recent things I know of for changes in general MONO behavior are the faster scripts project which was mostly about speeding up calls to prim properties.... there was a VERY recent change to get state changes faster, but that's been... less than 2 weeks? there were a few changes to rez/region-change behavior that lowered impact (scripts now initialize in queue rather than monopolizing the regions time) but that was well over a month or two back. and of course a whole slew of new calls and extra paramters for prim params.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4616 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...