8.5.1 Projector loosing sprite properties after 110 hours running.

[J O R I S webforumsuser@macromedia.com]

Hi,


I have the following problem:

After about 110 hours of non stop running, some(or all) sprites loose some or all of their property information. ("property not found") I wasn;t able to determine exactly which properties, but it looked like on one sprite the .ink property was unrecognised.
Also the screen gets messed up. It looks like all sprites suddenly have their trails turned on.
(None of my scripts turn trails on.)

I use setpref for errorlogging purposes, and have read in the knowledge base that this may cause memory leaks, however this cannot be responsible for the problem because the problem occurs before the logging starts.

setup:
- windows xp embedded with projectors created in dir 8.5.1
- projectors running are actually multiple instances of 1 executable. these instances each play their own movie (.dir) file.
- several projectors (5) running at the same time, with animate in background turned off.
- projectors communicate to a central data system written in c.
- used glu32 xtra and a dll to get to this data.
- other projectors are not affected and c-code runs fine. conclusion, only the one projector is affected.

I am now tryinig to find out more about the actual errors generated, so I improved my errorlogging.
Just have to wait 4.5 days for the result! :-/

If you have suggestions or similar experiences, please let me know.

Thanks,

Joris van Liempd

PS. sorry if this message was posted twice.

[JB]

I had trouble with a kiosk looping videosm never exactly determied
cause, but it seemed to be related to a memory leak.


The sprite props loss may just happend to be the first symtoms of used
up memory. You may want to trace the freeBlock, freeBytes and look for
any minute loss on each iteration.


Wonder if glu32 xtra may be causing a memory leak perhaps on each
instantiation, one could keep a single xtra instance stored in a global
the whole time.

[Arturo Toledo]

I´ve never had that problem but... you might work around the problem by
creating a timer handler. Once your application detects you are above say...
100 hours, re initialize your projector o forget windows (in case of using
MIAWs)...

ARturo


"J O R I S" <webforumsuser@macromedia.com> escribió en el mensaje
news:bqfbe5$nh8$1@forums.macromedia.com...

> Hi,
>
>
> I have the following problem:
>
> After about 110 hours of non stop running, some(or all) sprites loose some

or all of their property information. ("property not found") I wasn;t able
to determine exactly which properties, but it looked like on one sprite the
..ink property was unrecognised.

> Also the screen gets messed up. It looks like all sprites suddenly have

their trails turned on.

> (None of my scripts turn trails on.)
>
> I use setpref for errorlogging purposes, and have read in the knowledge

base that this may cause memory leaks, however this cannot be responsible
for the problem because the problem occurs before the logging starts.

>
> setup:
> - windows xp embedded with projectors created in dir 8.5.1
> - projectors running are actually multiple instances of 1 executable.

these instances each play their own movie (.dir) file.

> - several projectors (5) running at the same time, with animate in

background turned off.

> - projectors communicate to a central data system written in c.
> - used glu32 xtra and a dll to get to this data.
> - other projectors are not affected and c-code runs fine. conclusion, only

the one projector is affected.

>
> I am now tryinig to find out more about the actual errors generated, so I

improved my errorlogging.

> Just have to wait 4.5 days for the result! :-/
>
> If you have suggestions or similar experiences, please let me know.
>
> Thanks,
>
> Joris van Liempd
>
> PS. sorry if this message was posted twice.
>
>
>

[J O R I S webforumsuser@macromedia.com]

Thanks for your suggestions.



I already initialise the glu32 instances on startup. So there probably is no problem with the instantiating, although glu32 may still be leaking somewhere. However, I don't think the connection to a dll is such a complex thing to do, so for now I trust glu32.

I implemented a version of memory tracking and am now waiting for the results...

Did your kiosk-movie crash?

And if so, can you remember how long it took?

[J O R I S webforumsuser@macromedia.com]

Thanks Arturo.


Restarting after 100 hours might be a final hack around the problem.

Unfortunately restarting is very unwanted behaviour, so I'd rather find the real problem.

May be an upgrade to MX would do it?

Anyone?

Are there any fundamental or at least significant changes in MX where it concerns memory managment?

[Christoffer Enedahl]

> Are there any fundamental or at least significant changes in MX where it
concerns memory managment?

no, there are no fundamental or at least significant changes in MX period.
;-)

/Christoffer

[Andrew Morton]

>... You may want to trace the freeBlock, freeBytes...

They don't work on Windows. You have to use an xtra like buddyAPI
([url]www.mods.com.au[/url]) if you want to monitor memory usage or use the Windows Task
Manager (ctrl+shift+esc).

Andrew

[Arturo Toledo]

Director´s memory management issue has always been the ISSUE when it comes
to to bugs. I hope you can solve this Joris and let us know, ok?

Take care!

Arturo



"J O R I S" <webforumsuser@macromedia.com> escribió en el mensaje
news:bqhg76$dh7$1@forums.macromedia.com...

> Thanks Arturo.
>
>
> Restarting after 100 hours might be a final hack around the problem.
>
> Unfortunately restarting is very unwanted behaviour, so I'd rather find

the real problem.

>
> May be an upgrade to MX would do it?
>
> Anyone?
>
> Are there any fundamental or at least significant changes in MX where it

concerns memory managment?

>
>
>
>

[J O R I S webforumsuser@macromedia.com]

Too keep all of you who are interested up to date:

Memory seems the prime suspect. Virtual memory size is increasing slowly but steadily.

May be this is a memory framentation problem.

Is there a way to defragment memory?
Would it help to unload a lot of members from time to time?
(I may create a benchmark projector to explore this option)

The trail-effect is not caused by sprite trails.
It looks more like directors screen buffer is having difficulties.
Today we could witness the bug live:

The projector slows down and starts stuttering.
Trail effects start appearing during these stutters.
No errors reported in the log sofar.
Sound is okay.
CPU usage is about normal.

PageFaults are through the roof. 125 miljn and counting.

We are going to set the virtual memory manually to a high value now to see if this increases the uptime, (instead of letting Windows manage the VM.)

[Andrew Morton]

Can you get the projector to quit and restart every 24 hours? That was always
the usual workaround.

Andrew

[J O R I S webforumsuser@macromedia.com]

It is a requirement that the machine runs at least 100 hours. This is an absolute minimum.
However, this is far below our aim. So 110 (107) hrs is a bit close to this 100 hours and that is
why it needs to be solved.

While tracking Virtual memory, it turns out that the amount of Virtual memory increases by 2MB every
hour!
Seems like a leak to me.

Does anyone know what happens when you don't 'catch' return values. Can this result in memory leaks?
Or Itterative functions not being ended properly? Is this eating stack space, or heap, or whatever it is called?
Director always seems to ignore these things, but in a compiled language, this usaually means trouble... May be I should look for these constructions in my scripts?

[Christoffer Enedahl]

"J O R I S" <webforumsuser@macromedia.com> skrev i meddelandet
news:bqpcee$hkd$1@forums.macromedia.com...

> Seems like a leak to me.
>
> Does anyone know what happens when you don't 'catch' return values. Can

this result in memory leaks?

Only when you are creating a timeout. You need to catch the return value,
It's a bug in the timeout object.

> Or Itterative functions not being ended properly? Is this eating stack

space, or heap, or whatever it is called?

> Director always seems to ignore these things, but in a compiled language,

this usaually means trouble... May be I should look for these constructions
in my scripts?

Are using the xmlparser xtra? that one leaks.
In lingo a leak can emerge from circular references. like, one object have
another object in its property, that object have the first object in its
property too. When you stop using both objects, and dont clear the
properies, the objects will remain. causing a leak.

HTH/Chistoffer


code example of a leak:

--script leak
property pObject
on new me
return me
end
on SetObject me,aObject
pObject = aObject
end

--in other code
a = script("leak").new()
b = script("leak").new()
a.SetObject(b)
b.SetObject(a)

a = void
b = void