VisualWorks 7.7 and Later – Opening & Closing Window Does Not Free GDI Objects

We run automated UI tests, where we script our application’s UI from
Smalltalk. After running many tests, our test image needs to be
closed, as it consumes all available Windows GDI Object / GDI handles.

The maximum number of GDI Objects per process is set to 10000 by default.

We run VisualWorks 32 bit on Windows.

The problem cannot be found in 7.3 or 7.6. However, in 7.7 and 7.7.1
we can reproduce the problem using the following script in a
(commercial) base image:

500 timesRepeat: [| w | w := ScheduledWindow new. w open. w close]

If you run the script, you will notice that around 4 GDI Objects are
not freed per opened window. Forcing finalization does not free the
GDI Objects.

I have not done proper tests yet, but I suspect the problem can also
happen for other UI operations. One example is selecting items in a
tree view that triggers updates in a subcanvas.

Also look at thread “Have I Hit The Wall With Pixmaps? [VW 7.4 of 5
December 2005] on XP” in the vwnc mailing list.

Kind regards
Runar Jordahl

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IIRC, several of these were fixed in the about-to-be-released 7.8. We discovered these leaks when we put the UI on it's own OS thread. We ran similar tests with thousands of windows (including drawing into them) to eliminate the leaks we observed with the Windows resource monitor. So, I believe this is fixed.

David
_______________________________________
On Apr 4, 2011, at 1:24 AM, Runar Jordahl wrote:


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

That will be AR 62842.

On 4/4/2011 1:24 AM, Runar Jordahl wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

What is the status of AR 62842? Is it fixed? Will a patch appear for
VisualWorks 7.7.1?

I tried searching "Cincom Resolutions", but could not find it.

Runar


2011/4/8 Andres Valloud <[hidden email]>:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The current status is it's queued for 7.9.

On 4/12/2011 2:26 AM, Runar Jordahl wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Apr 4, 2011, at 1:24 AM, Runar Jordahl wrote:

Sigh. I wish I would have paid attention to this earlier. I would have saved myself 2 or so hours, proving what I thought might be the case to myself. And others as well too I imagine.

I know we may not have a stellar record when it comes to method comments and documentation, but... we do try, and in this case, it matters.

There's only 3 message sends in the above example: new, open, and close. Here's the method comment for ScheduledWindow close:

        "Close the receiver.
        Clients should rarely have to use this low-level interface directly, as it doesn't
        take window scheduling into account.  The normal way to close the window 'myWindow' is
        myWindow controller close - Close and unschedule the window, after checking first for changes in progress.
                or
        myWindow controller closeAndUnschedule - Close and unschedule the window."

Basically, what it says is "you shouldn't call this method unless you really know what you're doing." One could argue that such a "don't touch me method" ought not to have been named such an appealing/common thing; this method with this warning has been here since beginning of ObjectWorks time (at least after the BitBlt exodus in version 4.0).

If you do as the comment says, and do:

ScheduledWindow new open controller closeAndUnschedule

and use a tool such as GDIView, you'll see that if you garbage collect enough, watch instance counts of Icons, Pixmaps, Masks, and ScheduledWindows, that the instance counts return to their baseline value, as does GDI usage.

If you persist with the original example, you'll note by querying instance counts that Mask, Window, Pixmap, and Icon counts DON'T go down. And of course your GDI slowly grows.

Why is it worse than it used to be in older versions? I'm not entirely sure. Andres pointed out in an AR related to this, that we create more GDI objects than we used to per each window open. They'll get handled properly if the system is used right, but there is indeed more of them to handle than there used to be. So if the system was being pushed/abused, the rate would have increased, especially if you're not forcing/or really allowing, regular GCs to happen.

Putting a [ ] once block around the bodies of the methods for Icon class>>defaultShape and Icon class>>defaultFigure will reduce that back to the same rate as before.

The interested student can use this topic to segue into the mysteries of "why does 'ScheduledWindow allInstances size out' print 2x the number of windows I see open??"

--
Travis Griggs
Objologist
"I did not have time to write you a short program, so I wrote you a long one instead."


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

In our UI tests we use “controller closeNoTerminate” to close windows.
I think this is also OK, and I believe this method will eventually
call #closeAndUnschedule. The tests run all day, so any leakage of GDI
Objects will eventually have an impact. We have increased Windows’
limit of 10000 GDI Objects to 50000. It helps a bit, but we still have
too reboot our test-server many times per week.

I did some more analyses using VisualWorks 7.7.1 on Windows 7, with
“Version Id” #[68 47 68 224 77 1 0 0 68 47 68 224]. It seems like your
suggestion to use “controller closeAndUnschedule” reduce the leakage
by half. Here are my updated analyses:

1000 timesRepeat:
                [| w |
                w := ScheduledWindow new open.
                w controller closeAndUnschedule].
ObjectMemory globalGarbageCollect.
Around 4000 GDI Objects used, eventually it goes down to 2000.


1000 timesRepeat:
                [| w |
                w := ScheduledWindow new open.
                w close].
ObjectMemory globalGarbageCollect.
Around 4000 GDI Objects used. Does not seem to go down.


Runar

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi,

there is also AR 61459: Windows vm leaks an hDC each time an icon is set.
That is an VM problem and is fixed in the 7.8 VMs.
It causes the VM to leak two GDI objects per window opening.
So, with a 7.8 VM and #closeAndUnschedule, you should be down to 0 leaked handles again.

Ralf


Runar Jordahl wrote:

--
Ralf Propach, [hidden email]
Tel: +49 231 975 99 38   Fax: +49 231 975 99 20
Georg Heeg eK (Dortmund)
Handelsregister: Amtsgericht Dortmund  A 12812
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc