[Vm-dev] Windows VM broken for ioShowDisplay

Eliot Miranda eliot.miranda at gmail.com
Tue Nov 15 16:06:57 UTC 2022


Hi Marcel, Hi Nicolas, Hi Tobias,

On Tue, Nov 15, 2022 at 7:12 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

>
> 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.
>

Tangentially, (before the bug was fixed) the code that actually fails is
the fall-back traversal over scanlines to update the display
in ioShowDisplay.  I wondered in looking at this code whether it would be
better to cache the HDC dc device context for the display.  Aren't we
wasting cycles creating a new one for every display update?  Couldn't
stWin32Window.c keep a device context for stWindow around and use it as
long as the display hasn't changed?  Or is creating a device context super
cheap?

>
> 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> 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
>>
>>
>>
>>
>>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20221115/a91cadc9/attachment-0001.html>


More information about the Vm-dev mailing list