[Vm-dev] Windows VM broken for ioShowDisplay

Mon Nov 14 13:43:54 UTC 2022

Hi

> On 14. Nov 2022, at 14:17, 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.
> 
> 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.

The High-DPI-Code explicitly handles the multi-monitor stuff.
Nicolas, do you use one window stretched among several monitors or do you move the windows 
completely from one to anotheR?

	-Tobias

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