Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

[WE]: WebPicture memory woes (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Listbox "pops" in Cocoa when adding contents?
Next thread: Re: [WE] Which versions of IE (if any) are officially supported by the WE?


Re: No downgrade renewals?   -   Rubber Chicken Software Co.
  [WE]: WebPicture memory woes   -   Brad Hutchings
   Re: [WE]: WebPicture memory woes   -   Brad Hutchings
   Re: [WE]: WebPicture memory woes   -   Joe Ranieri
   Re: [WE]: WebPicture memory woes   -   Charles Yeomans
   Re: [WE]: WebPicture memory woes   -   Brad Hutchings
   Re: [WE]: WebPicture memory woes   -   Michael Diehr
   Re: [WE]: WebPicture memory woes   -   Joe Ranieri
   Re: [WE]: WebPicture memory woes   -   Michael Diehr
   Re: [WE]: WebPicture memory woes   -   Brad Hutchings
   Re: [WE]: WebPicture memory woes   -   Norman Palardy
   Re: [WE]: WebPicture memory woes   -   Brad Hutchings
   Re: [WE]: WebPicture memory woes   -   Brad Hutchings
    Re: WebPicture memory woes   -   Jym Morton

[WE]: WebPicture memory woes
Date: 27.03.12 18:18 (Tue, 27 Mar 2012 10:18:11 -0700)
From: Brad Hutchings
I'm running into some server-side memory woes with WebPicture. The app I'm building makes many large, dynamic pictures over the course of running, mostly in direct response to a user action. So, as I run "top" on the server and play with the interface to the app, I can see the "reserved" memory climb in chunks consistent with the size of newly created pictures. The bad part is that it never decreases. When I close a session (by closing a browser tab) and sign into a new session, the climbing continues, which indicates to me that memory for those pictures is never reclaimed.

I have been assigning pictures to WebImageViews by first creating a WebPicture:

wp = new WebPicture(p, Picture.FormatJPEG)
imgPreview.Picture = wp

I am noticing that if the picture p was cached and reused, I don't see the climb in memory usage. So my hunch here is that there might be a Dictionary behind the scenes keeping a reference to p and caching the exported data. So, I tried another approach:

data = p.GetData(Picture.FormatJPEG, Picture.QualityMax)
wp = new WebPicture(data, "picture.jpg")

But at runtime, I get an UnsupportedFormatException when creating that new WebPicture.

Known issue? Workarounds? Am I right about the caching that seems to keep references to these pictures around indefinitely?

-Brad

Re: [WE]: WebPicture memory woes
Date: 28.03.12 00:24 (Tue, 27 Mar 2012 16:24:52 -0700)
From: Brad Hutchings
<feedback://showreport?report_id 756>

On Mar 27, 2012, at 4:04 PM, Joe Ranieri wrote:

> On Tue, Mar 27, 2012 at 18:51, Brad Hutchings <<email address removed>> wrote:
>
>> Good to know. It would be very helpful to address this subtlety in the
>> docs. I use AddHandler pretty liberally, and yet, every different day I use
>> it, I end up going to the docs to re-read the explanation. It's just not as
>> engrained in my memory as a for loop. So a hint about this issue in the
>> docs would be most helpful.
>>
>> -Brad
>> --
>> Brad Hutchings
>> Hutchings Software
>>
> Please file a Feedback ticket against the documentation.
>
> --
> Joe Ranieri
> Mac Frameworks & Compiler
> Real Software, Inc.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: [WE]: WebPicture memory woes
Date: 28.03.12 00:04 (Tue, 27 Mar 2012 19:04:02 -0400)
From: Joe Ranieri
On Tue, Mar 27, 2012 at 18:51, Brad Hutchings <<email address removed>> wrote:

> Good to know. It would be very helpful to address this subtlety in the
> docs. I use AddHandler pretty liberally, and yet, every different day I use
> it, I end up going to the docs to re-read the explanation. It's just not as
> engrained in my memory as a for loop. So a hint about this issue in the
> docs would be most helpful.
>
> -Brad
> --
> Brad Hutchings
> Hutchings Software
>

Please file a Feedback ticket against the documentation.

--
Joe Ranieri
Mac Frameworks & Compiler
Real Software, Inc.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: [WE]: WebPicture memory woes
Date: 28.03.12 00:01 (Tue, 27 Mar 2012 19:01:19 -0400)
From: Charles Yeomans

On Mar 27, 2012, at 4:30 PM, Brad Hutchings wrote:

> I've isolated one issue with the runtime that accounts for some of the leak. If you have a WebImageView, and you don't set it's picture property to nil in the WebPage's Close event handler (or its picture is not nil when the WebPage goes away), its WebImage and any picture referenced will stick around in memory indefinitely. I will construct an example and file a bug report on this.
>
> Another thing I figured out (which isn't documented, but I guess not terribly surprising) is that AddHandler implicitly adds a reference to the object that has the handler. For example, I was using a Timer in a class that handles a picture cache ("PictureCache") for me. The Timer's action is a method in my PictureCache class, set via AddHandler, and it removes stale data from the cache. The PictureCache object does not get destroyed unless the handler for the timer is removed first. Further, the Timer appears to stop firing once the Session closes, so it never gets a chance to kill all the stale pictures! They just live like zombies until the app is killed.
>
> I think these two findings have calmed my memory leak down considerably, possibly mostly, and if I'm lucky completely.

You can prevent reference cycles in such situations by using a delegate of a shared method, or using WeakAddressOf to create a delegate of an object method.

Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: [WE]: WebPicture memory woes
Date: 27.03.12 23:51 (Tue, 27 Mar 2012 15:51:24 -0700)
From: Brad Hutchings
On Mar 27, 2012, at 3:39 PM, Joe Ranieri wrote:

> This has nothing to do with AddHandler and everything to do with AddressOf
> -- AddHandler just holds on to the delegate you give it. If you want a weak
> reference for AddHandler, use WeakAddressOf.
>
> --
> Joe Ranieri
> Mac Frameworks & Compiler
> Real Software, Inc.

Good to know. It would be very helpful to address this subtlety in the docs. I use AddHandler pretty liberally, and yet, every different day I use it, I end up going to the docs to re-read the explanation. It's just not as engrained in my memory as a for loop. So a hint about this issue in the docs would be most helpful.

-Brad

Re: [WE]: WebPicture memory woes
Date: 27.03.12 23:49 (Tue, 27 Mar 2012 15:49:06 -0700)
From: Michael Diehr
On Mar 27, 2012, at 3:39 PM, Joe Ranieri wrote:

> On Tue, Mar 27, 2012 at 18:35, Michael Diehr <<email address removed>> wrote:
>
>> On Mar 27, 2012, at 1:30 PM, Brad Hutchings wrote:
>>> Another thing I figured out (which isn't documented, but I guess not
>> terribly surprising) is that AddHandler implicitly adds a reference to the
>> object that has the handler.
>>
>> We had a similar issue with Delegates, which led to the call for Weak
>> Delegates.
>>
>> Would it make sense for a similar option with Handlers, or should they
>> just default to being Weak in the first place?
>
> This has nothing to do with AddHandler and everything to do with AddressOf
> -- AddHandler just holds on to the delegate you give it. If you want a weak
> reference for AddHandler, use WeakAddressOf.

Thanks Joe, didn't know that.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: [WE]: WebPicture memory woes
Date: 27.03.12 23:39 (Tue, 27 Mar 2012 18:39:42 -0400)
From: Joe Ranieri
On Tue, Mar 27, 2012 at 18:35, Michael Diehr <<email address removed>> wrote:

> On Mar 27, 2012, at 1:30 PM, Brad Hutchings wrote:
> > Another thing I figured out (which isn't documented, but I guess not
> terribly surprising) is that AddHandler implicitly adds a reference to the
> object that has the handler.
>
> We had a similar issue with Delegates, which led to the call for Weak
> Delegates.
>
> Would it make sense for a similar option with Handlers, or should they
> just default to being Weak in the first place?

This has nothing to do with AddHandler and everything to do with AddressOf
-- AddHandler just holds on to the delegate you give it. If you want a weak
reference for AddHandler, use WeakAddressOf.

--
Joe Ranieri
Mac Frameworks & Compiler
Real Software, Inc.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: [WE]: WebPicture memory woes
Date: 27.03.12 23:35 (Tue, 27 Mar 2012 15:35:50 -0700)
From: Michael Diehr
On Mar 27, 2012, at 1:30 PM, Brad Hutchings wrote:
> Another thing I figured out (which isn't documented, but I guess not terribly surprising) is that AddHandler implicitly adds a reference to the object that has the handler.

We had a similar issue with Delegates, which led to the call for Weak Delegates.

Would it make sense for a similar option with Handlers, or should they just default to being Weak in the first place?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: [WE]: WebPicture memory woes
Date: 27.03.12 21:52 (Tue, 27 Mar 2012 13:52:30 -0700)
From: Brad Hutchings
Yeah, it's usually easier to RTFM than to DTFUB ("deduce the underlying behavior"). OK, here is another one for the archives and maybe a documentation rewrite...

In WE apps, WebApplication.timeout is how long it takes for an abandoned Session to close itself. It may or may not be how long an app with WebApplication.autoquit set true takes to close itself after the last session is destroyed.

Quite confusing, as you might set app.timeout very high in an attempt to not let the app quit. But guess what? If you're sessions are referencing big objects like pictures, the sessions don't get destroyed for a long time, and pictures stick around since they are referenced. Ouch.

-Brad

Re: [WE]: WebPicture memory woes
Date: 27.03.12 21:38 (Tue, 27 Mar 2012 14:38:49 -0600)
From: Norman Palardy

On Mar 27, 2012, at 2:30 PM, Brad Hutchings wrote:

> Another thing I figured out (which isn't documented, but I guess not terribly surprising) is that AddHandler implicitly adds a reference to the object that has the handler. For example, I was using a Timer in a class that handles a picture cache ("PictureCache") for me. The Timer's action is a method in my PictureCache class, set via AddHandler, and it removes stale data from the cache. The PictureCache object does not get destroyed unless the handler for the timer is removed first. Further, the Timer appears to stop firing once the Session closes, so it never gets a chance to kill all the stale pictures! They just live like zombies until the app is killed.

This one makes perfect sense although it may not be documented clearly

Norman Palardy

Real World 2012, THE Real Studio Event of the year!
http://realsoftware.com/community/realworld.php

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: [WE]: WebPicture memory woes
Date: 27.03.12 21:30 (Tue, 27 Mar 2012 13:30:13 -0700)
From: Brad Hutchings
I've isolated one issue with the runtime that accounts for some of the leak. If you have a WebImageView, and you don't set it's picture property to nil in the WebPage's Close event handler (or its picture is not nil when the WebPage goes away), its WebImage and any picture referenced will stick around in memory indefinitely. I will construct an example and file a bug report on this.

Another thing I figured out (which isn't documented, but I guess not terribly surprising) is that AddHandler implicitly adds a reference to the object that has the handler. For example, I was using a Timer in a class that handles a picture cache ("PictureCache") for me. The Timer's action is a method in my PictureCache class, set via AddHandler, and it removes stale data from the cache. The PictureCache object does not get destroyed unless the handler for the timer is removed first. Further, the Timer appears to stop firing once the Session closes, so it never gets a chance to kill all the stale pictures! They just live like zombies until the app is killed.

I think these two findings have calmed my memory leak down considerably, possibly mostly, and if I'm lucky completely.

-Brad

Re: [WE]: WebPicture memory woes
Date: 27.03.12 18:47 (Tue, 27 Mar 2012 10:47:15 -0700)
From: Brad Hutchings
Additional note: WebPicture has some undocumented properties, including Cached (boolean) and OnDownloaded (a delegate). Cached is not assignable. I tried, thinking it might just remove it from the cache.

There is a feedback on the undocumented Cached property:

<feedback://showreport?report_id 586>

-Brad