[Vm-dev] Windows VM broken for ioShowDisplay

Tue Nov 15 15:11:31 UTC 2022

Hi Eliot --

> There are lots of differences between the branch I use for Virtend (the branch is called “virtend”) and the tip. 

Well, this issue was about the "Cog" branch and things around ioShowDisplay() and GDI and DirectDraw etc. in sqWin32Window.c. I just used git blame on the file and I am still certain that we did not touch that code in years. :-) That cursor stuff was touched in 2011.

Unlike macOS, Windows backwards compatibility is still great. But that's just my working hypothesis for these kinds of issues. Has worked quite well so far.

So, unfortunately, we have still no better idea on when exactly this bug was triggered. :-/ ... but it seems to be fixed. Yay. ;-)

Best,
Marcel
Am 15.11.2022 15:58:21 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Hi Marcel,

On Nov 14, 2022, at 5:17 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:

Hi Nicolas --

Hmm... we haven't touched that win32 platform graphics code in many years. It was not necessary to get that high-dpi stuff working.

That’s not true.  There are lots of differences between the branch I use for Virtend (the branch is called “virtend”) and the tip.  And I can confirm that the virtend branch, built using the clang/MSVC tool chain, works fine and does not crash.

Just check out the virtend branch and look for yourself.

Here are primitives you can try to disable:

DisplayScreen >> #forceDisplayUpdate (prim 231)
DisplayScreen class >> #actualScreenScaleFactor (prim #primitiveScreenScaleFactor)
DisplayScreen >> #primitiveDeferUpdates: (prim 126) -- graphics will flicker then
DisplayScreen >> #primShowRect... (prim 127) + #primRetryShowRect... (prim 127)

Maybe this helps. My GDI objects are stable at about 20.

Best,
Marcel

Am 14.11.2022 14:00:44 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
Hi Marcel,

I understand that the bug is not so widespread, or it would be yet fixed.

Still, the bug exists, I consistently reach the 10,000 GDI object limit

quite fast (about 45 objects per second).

Could it be revealed only in some specific image configuration?

I mostly use updated old images, rather than freshly distributed...

Or could it be some OS/hardware configuration?

I'm on an old windows 10 version (1909) and use a dual screen (laptop +

external monitor).

And Tobias, I don't think that ostracizing every contributor making a

mistake (if it really is one) is the best idea.

The only way I know to not make a mistake at all is to not program at all.

So no, we won't revoke your license, sorry, you have to keep on programming

;)

I already made the fix, but I guessed wrong, it did not solve the leak...

Nicolas

Le lun. 14 nov. 2022 à 13:43, Marcel Taeumel a

écrit :

>

> Hi all --

>

> I cannot even see a crash or a growth in GDI objects in a recent OSVM

> build:

>

> OS: Win32 10.0 X64

> VM: 2022*1109*0631 (5a9222cd1)

> SQ: Squeak6.0 #22114 (64 bit)

>

> OS: Win32 10.0 X64

> VM: 2022*1109*0631 (5a9222cd1)

> SQ: Squeak6.1alpha #22271 (64 bit)

>

> Then I tried Windows 11, all looks fine. Except that the primitive still

> reports "Win32 10.0 X64" for some reason...

>

> OS: Win32 10.0 X64 ... win11

> VM: 2022*0602*1410 (c9fd365)

> SQ: Squeak6.0 #22114 (64 bit)

>

> OS: Win32 10.0 X64 ... win11

> VM: 2022*1109*0631 (5a9222c)

> SQ: Squeak6.0 #22114 (64 bit)

>

> OS: Win32 10.0 X64 ... win11

> VM: 2022*0602*1410 (c9fd365)

> SQ: Squeak6.1alpha #22271 (64 bit)

>

> OS: Win32 10.0 X64 ... win11

> VM: 2022*1109*0631 (5a9222c)

> SQ: Squeak6.1alpha #22271 (64 bit)

>

> ... so ... who can reproduce this issue where?

>

> Best,

> Marcel

>

>

> Am 14.11.2022 12:59:40 schrieb Marcel Taeumel :

> Hi Tobias --

>

> There is no leak of GDI objects on my machine. Squeak 6.0 VMs seem to be

> fine... Please let us clarify this issue first.

>

> Best,

> Marcel

>

> Am 14.11.2022 12:57:17 schrieb Tobias Pape :

>

> Maybe someone can revoke my C-license?

> It's the second time I introduced a Leak with the DPI stuff -.-

>

> > On 14. Nov 2022, at 12:13, Nicolas Cellier wrote:

> >

> > Hmm, maybe a clue:

> >

> > static double getDpiSystem(void)

> > {

> > return (double) GetDeviceCaps(GetWindowDC(stWindow), LOGPIXELSY);

> > }

> >

> > shouldn't there be a ReleaseDC here ?

>

> Probably. I didn't know that this stuff acquired something, but is makes

> sense.

> Shall I or do you want?

>

> -T

>

> >

> > Le lun. 14 nov. 2022 à 12:10, Nicolas Cellier a écrit :

> > I confirm that it is a GDI LEAK.

> > If I display the number of GDI objects in the task manager, I see that

> the number grows up to 10,000 at which time the image hangs...

> >

> > Le lun. 14 nov. 2022 à 11:24, Nicolas Cellier a écrit :

> > Sorry, for shorten message, continued below...

> >

> > Le lun. 14 nov. 2022 à 11:18, Nicolas Cellier a écrit :

> > Hi all,

> > as Eliot already reported in October, after a few minutes, the 64bits

> image locks up on windows.

> > The console reports an error from within ioShowDisplay

> >

> > SetDIBitsToDevice failed (0)

> > width=1364,height=757,bits=7FF7471D68E8,dc=FFFFFFFF9D010B72

> >

> > then several other gdi calls start to fail, like

> >

> > CreateCursor failed (0)

> >

> > a bit further, SetDIBitsToDevice failed (8), the error message concerns

> >

> > The error message a bit further is about insufficient memory resources

> to perform the SetDIBitsToDevice

> >

> > If I open an image, leave it alone, and observe the Squeak.exe process

> in TaskManager, I clearly see a memory leak.

> > The error happens after about 15 or 16Mbytes increase.

> > So we should track the origin of un-released resources, and the problem

> will then probably vanish.

> >

> > For now, it's a show-stopper for me.

> >

> > Nicolas

>

>

>

Hi Marcel,
I understand that the bug is not so widespread, or it would be yet fixed.
Still, the bug exists, I consistently reach the 10,000 GDI object limit quite fast (about 45 objects per second).

Could it be revealed only in some specific image configuration?
I mostly use

updated

old images, rather than freshly distributed...
Or could it be some OS/hardware configuration?
I'm on an old windows 10 version (1909) and use a dual screen (laptop + external monitor).

And Tobias, I don't think that ostracizing every contributor making a mistake (if it really is one) is the best idea.
The only way I know to not make a mistake at all is to not program at all.
So no, we won't revoke your license, sorry, you have to keep on programming ;)
I already made the fix, but I guessed wrong, it did not solve the leak...

Nicolas

Le lun. 14 nov. 2022 à 13:43, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> a écrit :

Hi all --

I cannot even see a crash or a growth in GDI objects in a recent OSVM build:

OS: Win32 10.0 X64
VM: 202211090631 (5a9222cd1)
SQ: Squeak6.0 #22114 (64 bit)

OS: Win32 10.0 X64
VM: 202211090631 (5a9222cd1)
SQ: Squeak6.1alpha #22271 (64 bit)

Then I tried Windows 11, all looks fine. Except that the primitive still reports "Win32 10.0 X64" for some reason...

    OS: Win32 10.0 X64 ... win11
    VM: 202206021410 (c9fd365)
    SQ: Squeak6.0 #22114 (64 bit)

    OS: Win32 10.0 X64 ... win11
    VM: 202211090631 (5a9222c)
    SQ: Squeak6.0 #22114 (64 bit)

    OS: Win32 10.0 X64 ... win11
    VM: 202206021410 (c9fd365)
    SQ: Squeak6.1alpha #22271 (64 bit)

    OS: Win32 10.0 X64 ... win11
    VM: 202211090631 (5a9222c)
    SQ: Squeak6.1alpha #22271 (64 bit)

... so ... who can reproduce this issue where?

Best,
Marcel

Am 14.11.2022 12:59:40 schrieb Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]>:

Hi Tobias --

There is no leak of GDI objects on my machine. Squeak 6.0 VMs seem to be fine... Please let us clarify this issue first.

Best,
Marcel

Am 14.11.2022 12:57:17 schrieb Tobias Pape <das.linux at gmx.de [mailto:das.linux at gmx.de]>:

Maybe someone can revoke my C-license?
It's the second time I introduced a Leak with the DPI stuff -.-

> On 14. Nov 2022, at 12:13, Nicolas Cellier wrote:
>
> Hmm, maybe a clue:
>
> static double getDpiSystem(void)
> {
> return (double) GetDeviceCaps(GetWindowDC(stWindow), LOGPIXELSY);
> }
>
> shouldn't there be a ReleaseDC here ?

Probably. I didn't know that this stuff acquired something, but is makes sense.
Shall I or do you want?

-T

>
> Le lun. 14 nov. 2022 à 12:10, Nicolas Cellier a écrit :
> I confirm that it is a GDI LEAK.
> If I display the number of GDI objects in the task manager, I see that the number grows up to 10,000 at which time the image hangs...
>
> Le lun. 14 nov. 2022 à 11:24, Nicolas Cellier a écrit :
> Sorry, for shorten message, continued below...
>
> Le lun. 14 nov. 2022 à 11:18, Nicolas Cellier a écrit :
> Hi all,
> as Eliot already reported in October, after a few minutes, the 64bits image locks up on windows.
> The console reports an error from within ioShowDisplay
>
> SetDIBitsToDevice failed (0)
> width=1364,height=757,bits=7FF7471D68E8,dc=FFFFFFFF9D010B72
>
> then several other gdi calls start to fail, like
>
> CreateCursor failed (0)
>
> a bit further, SetDIBitsToDevice failed (8), the error message concerns
>
> The error message a bit further is about insufficient memory resources to perform the SetDIBitsToDevice
>
> If I open an image, leave it alone, and observe the Squeak.exe process in TaskManager, I clearly see a memory leak.
> The error happens after about 15 or 16Mbytes increase.
> So we should track the origin of un-released resources, and the problem will then probably vanish.
>
> For now, it's a show-stopper for me.
>
> Nicolas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20221115/c7d7eb60/attachment-0001.html>