Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003976opensim[REGION] Script Functionspublic2009-08-07 09:092020-03-19 15:59
Assigned Tojustincc 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003976: memory leaks with osSetDynamicTextureURL and related

i found out that the use of the dynamic textures might be a nasty source of memory leaks. i tested the following script on an empty standalone and after
a while the server consumes some hundreds of megabytes of memory. When i stop the script (click it again to jump back to default state) i get some memory freed, but not all.

i started with about 100mb. after about 150 iterations i reached about 1.8GB. i stopped and deleted the prim with the script and ended with about 900mb.

i love these dynamic texture functions and hope this will get fixed in the near future.


Additional Informationstring did = "";
// link to a larger image
string url = ""; [^]

li() {
// when i do:
// did = osSetDynamicTextureURL(did, "image" ,url , "", 1);
// memory get reused but but the image didn't get reloaded/updated.
// if memory is logical assigned to the dynamic id (did) then a
// reload of the given/new url might solve this. but even then
// it left some kb and grows the overall mem usage.
    osSetDynamicTextureURL(did, "image" ,url , "", 1);

default {
    state_entry() {
        llOwnerSay("default state");
    touch_start(integer n) {
        state go;

state go {
    state_entry() {
        llOwnerSay("loader state");
    timer() {
    touch_start(integer n) {
        state default;
TagsNo tags attached.
Git Revision or version numberca5da5face978860ee2071a63f735ebc9aa49aee
Run ModeStandalone (1 Region)
Physics EngineODE
Script Engine
EnvironmentMono / Linux32
Mono Versiontrunk
Attached Filespng file icon memleak.png [^] (18,019 bytes) 2010-02-21 09:13

- Relationships
child of 0003986closed [OSSL] 

-  Notes
otakup0pe (developer)
2009-08-07 09:15

i'm running many scripts using this function and am not seeing such severe leaks. do you have a memory texture cache enabled ? i have run out of disk space a few times before i manually tuned my cache.
thomax (reporter)
2009-08-07 09:39

here is my FlotsamCache.ini

    CacheDirectory = ./assetcache
    LogLevel = 0
    HitRateDisplay = 100
    MemoryCacheEnabled = false
    MemoryCacheTimeout = 2
    FileCacheTimeout = 2
    FileCleanupTimer = .166 ;roughly every 10 minutes
    CacheDirectoryTiers = 1
    CacheDirectoryTierLength = 3
thomax (reporter)
2009-08-07 09:42

oh, and i also used to use this functions alot. but because of the constant increase of memory i stop all those script actions till i can't repro using the above script.
otakup0pe (developer)
2009-08-07 09:45

our flotsamcache's are pretty similar. for reference i have about a dozen prims refreshing urls every five minutes and a handful refreshing every minute.
thomax (reporter)
2009-08-07 09:48

well.. but i use very huge images in the test script and load them fast to get a clear result. the repro works on a debian with trunk mono and trunk opensim. best is to use a clear standalone with nothing else but you, a prim and the script.
aduffy70 (reporter)
2009-08-07 22:50

I see this also on svn9961, mono 2.4, 32bit Ubuntu 8.10. It wasn't happening on svn9395. Three scripts updating every 5 minutes increase memory allocated by ~500Mb over 12 hours. You can see the memory allocated cycling... it rises then drops, rises then drops, but everytime it drops it doesn't drop quite as low as it was before.
thomax (reporter)
2009-08-07 23:41

i added the following comment to the script:

when i do:
   did = osSetDynamicTextureURL(did, "image" ,url , "", 1);
memory get reused but but the image didn't get reloaded/updated.
if memory is logical assigned to the dynamic id (did) then a
reload of the given/new url might solve this. but even then
it left some kb and grows the overall mem usage.
thomax (reporter)
2009-08-08 00:23

ok, i read the implementing source code and it seems that the update code is completely not implemented. if this would be done we could close this mantis. until then you need to make a 'new texture' per each call which will increase memory till you stop calling the dynamic texture functions.

to use this functions in a updating sense in the current state is a very high risk and is not recommended. the thread level should be increased from 'VeryLow' to 'Severe'.
thomax (reporter)
2009-08-17 00:59

can someone confirm this issue, please?
thomax (reporter)
2010-02-21 09:27


i added a memory leak chart to this nasty bug.
the function is really unusable.

i changed the script so, that it loads the image
just every 5 seconds, not every 2 seconds.
the image is a 1.8 MB large jpg file.
i ran the script for ca. 15 minutes and the sim
memory growth from ca. 109MB to 643MB, thats
about 534MB leak in 15 minutes.

this is with the recent git commit:

here is another link to the chart image: [^] [^]

it would be nice if someone could confirm this bug
and could help to get it fixed, somehow.

nebadon (administrator)
2012-02-24 09:41

is this still a problem? I have been running this script for several hours and have absolutely no memory leaking so far, I am using SuSE Linux 11.4 with mono 2.10.8, if this is no longer a problem for you I would like to close this ticket
thomax (reporter)
2012-02-24 12:40

unfortunately this bug still exist.

what i did to proof it:

i made a prim on a sim which is up since about 30 days with less of
200mb memory consumption. i placed the script from the original
prim and clicked on the prim. the load loop began. i checked memory
consumption and in between the first 120 seconds the memory increases
from 200mb to 900mb. then i stopped it because it would consume all
memory in very short time.

so, please do not close the mantis. this bug is still there. just try it
with the script above.


nebadon (administrator)
2012-02-24 15:15

ok I will not close it, but unfortunately I am unable to recreate the issue myself so far, as you can see below its been running for 2 hours 21 minutes now with zero leaking, I will continue to let it run and see what happens.

Region (OKC Sandbox2) # show up
Time now is 2/24/2012 4:13:52 PM
Server has been running since Friday, 2/24/2012 1:52:22 PM
That is an elapsed time of 02:21:30.1476650

Region (OKC Sandbox2) # show stats

Abnormal client thread terminations: 0

Dilatn SimFPS PhyFPS AgntUp RootAg ChldAg Prims AtvPrm AtvScr ScrLPS
  1.00 54 55.0 0.0 0 0 1563 0 322 11

PktsIn PktOut PendDl PendUl UnackB TotlFt NetFt PhysFt OthrFt AgntFt ImgsFt
     8 8 0 0 0 2.3 0.0 1.7 0.0 0.3 0.3

Allocated to OpenSim : 84 MB

Region (OKC Sandbox2) #
justincc (administrator)
2012-08-14 16:07

This may now be resolved by the changes as of git master commit eeef9d7e990cf158de5c143de546fc671169b3bd, which will also be in 0.7.4-rc1
justincc (administrator)
2012-09-21 16:50

Closed due to lack of feedback and no further reports.

- Issue History
Date Modified Username Field Change
2009-08-07 09:09 thomax New Issue
2009-08-07 09:09 thomax Git Revision => ca5da5face978860ee2071a63f735ebc9aa49aee
2009-08-07 09:09 thomax SVN Revision => 0
2009-08-07 09:09 thomax Run Mode => Standalone (1 Region)
2009-08-07 09:09 thomax Physics Engine => ODE
2009-08-07 09:09 thomax Environment => Mono / Linux32
2009-08-07 09:09 thomax Mono Version => trunk
2009-08-07 09:15 otakup0pe Note Added: 0012753
2009-08-07 09:39 thomax Note Added: 0012756
2009-08-07 09:42 thomax Note Added: 0012758
2009-08-07 09:45 otakup0pe Note Added: 0012759
2009-08-07 09:48 thomax Note Added: 0012760
2009-08-07 22:50 aduffy70 Note Added: 0012787
2009-08-07 23:41 thomax Note Added: 0012788
2009-08-07 23:41 thomax Additional Information Updated
2009-08-08 00:23 thomax Note Added: 0012789
2009-08-09 05:51 Fly-Man- Relationship added child of 0003986
2009-08-17 00:59 thomax Note Added: 0012905
2009-08-17 00:59 thomax Status new => feedback
2010-02-21 09:13 thomax File Added: memleak.png
2010-02-21 09:22 thomax Note Added: 0015042
2010-02-21 09:27 thomax Note Added: 0015043
2010-02-21 09:27 thomax Priority normal => high
2010-02-21 09:27 thomax Note Deleted: 0015042
2012-02-24 09:41 nebadon Note Added: 0020966
2012-02-24 12:40 thomax Note Added: 0020970
2012-02-24 12:40 thomax Status feedback => new
2012-02-24 15:15 nebadon Note Added: 0020974
2012-08-14 16:07 justincc Note Added: 0022071
2012-08-18 04:32 DMX04 Issue cloned: 0006202
2012-09-21 16:50 justincc Note Added: 0022652
2012-09-21 16:50 justincc Status new => closed
2012-09-21 16:50 justincc Assigned To => justincc
2012-09-21 16:50 justincc Resolution open => fixed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker