[Vm-dev] Windows VM broken for ioShowDisplay

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Nov 14 13:00:21 UTC 2022


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> 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 <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>:
>
> 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/20221114/b54fb058/attachment-0001.html>


More information about the Vm-dev mailing list