[Vm-dev] Windows VM broken for ioShowDisplay
Eliot Miranda
eliot.miranda at gmail.com
Tue Nov 15 14:58:09 UTC 2022
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: 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>:
>>>>
>>>>
>>>> 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/20221115/f0705b2e/attachment-0001.html>
More information about the Vm-dev
mailing list