[Bug 10522] New: endless WM_PAINT loop bug (update regions, queue paint count)
http://bugs.winehq.org/show_bug.cgi?id=10522 Summary: endless WM_PAINT loop bug (update regions, queue paint count) Product: Wine Version: CVS/GIT Platform: PC URL: http://www.microsoft.com/whdc/devtools/debugging/install x86.mspx OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-user AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9265) --> (http://bugs.winehq.org/attachment.cgi?id=9265) trace with WINEDEBUG=+tid,+message,+win,+server Hello, I've seen this bug a while ago in other apps but ignored it because it was not easily to reproduce. Well until recently when I tested some stuff with windbg from "Debugging Tools for Windows" (Microsoft). I used debugging tools version 6.8.4.0 and recent GIT (wine-0.9.49-302-g58b85bb). Immediately when a child window was opened using toolbar (register, locals, .. whatever), windbg would become unresponsive, eating most CPU. Happens in both GUI modes - "floating/docking toolwindow" and "MDI emulation. Though "MDI emulation" is more obvious, it actually shows the endless refreshing (window caption). Attached is WINEDEBUG=+tid,+message,+win,+server log. Additionally I added a trace message which prints the current queue paint count (when incremented or fetched) which makes some things easier to spot. Printed as "inc_queue_paint_count: %d" and "get_message_paint_count: %d". The window hierarchy is as follows: --- snip --- *root*=0x10020 Shell_TrayWnd=0x10022 WinDbgFrameClass=0x10024 DockClass=0x10026 ToolbarWindow32=0x10028 msctls_statusbar32=0x1002a tooltips_class32=0x1002e WinBaseClass=0x10030 ToolbarWindow32=0x10032 SysListView32=0x10034 SysHeader32=0x10036 RichEdit20W=0x10038 --- snip --- After the child windows are created the queue paint count never drops to zero, resulting in endless WM_PAINT processing. Maybe some update (region) code path missed or flags problem? I played a bit with ignoring null region updates and it seemed to help a bit (preventing endless WM_PAINT loop) though other stuff wasn't drawn properly then. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #1 from Austin English <austinenglish(a)gmail.com> 2008-06-03 13:06:10 --- Is this still an issue in 1.0-rc3? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #2 from Anastasius Focht <focht(a)gmx.net> 2008-06-10 04:54:01 --- Hello, --- quote --- Is this still an issue in 1.0-rc3? --- quote --- Sure. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #3 from Anastasius Focht <focht(a)gmx.net> 2008-07-22 01:28:20 --- Hello, Visual Studio .NET 2005 (http://appdb.winehq.org/objectManager.php?sClass=version&iId=4494) has a similar issue. In the "welcome"/"start page" there is an area/control "Visual Studio Headlines" being constantly redrawn, eating 50-100% of one CPU. +tid,+msg,+win,+server between successive RedrawWindow calls (repeats forever): --- snip --- .. 0009:trace:win:RedrawWindow 0x10114 rect (0,0)-(204,66) flags: RDW_INVALIDATE RDW_ERASE 0009: redraw_window( window=0x10114, flags=00000005, region={{0,0;204,66}} ) 0009: redraw_window() = 0 0009:trace:win:release_dc 0x10114 0x30c 0009: set_caret_info( flags=00000006, handle=0x10114, x=0, y=0, hide=-1, state=1 ) 0009: set_caret_info() = ACCESS_DENIED { full_handle=(nil), old_rect={0,0;0,0}, old_hide=1, old_state=1 } 0009: get_update_region( window=0x10114, from_child=(nil), flags=00000023 ) 0009: get_update_region() = 0 { child=0x10114, flags=00000002, total_size=16, region={{332,718;536,777}} } 0009:trace:win:GetDCEx hwnd 0x10114, hrgnClip 0xbb0c, flags 00010080 0009:trace:win:GetDCEx found valid 0x12ecb0 dce [0x10114], flags 00000002 0009: get_visible_region( window=0x10114, flags=00000082 ) 0009: get_visible_region() = 0 { top_win=0x1002c, top_rect={280,108;1526,798}, win_rect={332,718;536,784}, total_size=16, region={{332,718;536,777}} } 0009:trace:win:GetDCEx (0x10114,0xbb0c,0x10080): returning 0x30c 0009:trace:win:GetWindowRect hwnd 0x10114 ((332,718)-(536,784)) 0009:trace:win:release_dc 0x10114 0x30c 0009: get_message( flags=00000000, get_win=(nil), get_first=00000000, get_last=ffffffff, hw_id=00000000, wake_mask=00000040, changed_mask=000004ff ) 0009: get_message() = 0 { win=0x10114, type=6, msg=0000000f, wparam=0, lparam=0, info=0, x=0, y=0, time=0000587e, hw_id=00000000, active_hooks=80000000, total=0, data={} } 0009:trace:msg:peek_message got type 6 msg f (WM_PAINT) hwnd 0x10114 wp 0 lp 0 0009: get_message( flags=00000001, get_win=(nil), get_first=00000000, get_last=ffffffff, hw_id=00000000, wake_mask=00000040, changed_mask=000004ff ) 0009: get_message() = 0 { win=0x10114, type=6, msg=0000000f, wparam=0, lparam=0, info=0, x=0, y=0, time=0000587f, hw_id=00000000, active_hooks=80000000, total=0, data={} } 0009:trace:msg:peek_message got type 6 msg f (WM_PAINT) hwnd 0x10114 wp 0 lp 0 0009: set_caret_info( flags=00000006, handle=0x10114, x=0, y=0, hide=1, state=0 ) 0009: set_caret_info() = ACCESS_DENIED { full_handle=(nil), old_rect={0,0;0,0}, old_hide=1, old_state=1 } 0009: get_update_region( window=0x10114, from_child=(nil), flags=0000002f ) 0009: get_update_region() = 0 { child=0x10114, flags=00000004, total_size=16, region={{332,718;536,777}} } 0009:trace:win:GetDCEx hwnd 0x10114, hrgnClip 0xbb18, flags 00010080 0009:trace:win:GetDCEx found valid 0x12ecb0 dce [0x10114], flags 00000002 0009: get_visible_region( window=0x10114, flags=00000082 ) 0009: get_visible_region() = 0 { top_win=0x1002c, top_rect={280,108;1526,798}, win_rect={332,718;536,784}, total_size=16, region={{332,718;536,777}} } 0009:trace:win:GetDCEx (0x10114,0xbb18,0x10080): returning 0x30c 0009:trace:win:BeginPaint hdc = 0x30c box = ((0,0)-(204,59)), fErase = 0 0009:trace:win:WIN_SetWindowLong 0x100d6 0 0 W 0009:trace:win:WIN_SetWindowLong 0x100d6 0 0 W 0009:trace:win:GetDCEx hwnd 0x10114, hrgnClip (nil), flags 00000003 0009:trace:win:GetDCEx found valid 0x12f978 dce [0x10114], flags 00000003 0009:trace:win:GetDCEx (0x10114,(nil),0x3): returning 0x384 0009:trace:win:release_dc 0x10114 0x384 0009:trace:win:RedrawWindow 0x10114 rect (0,0)-(204,66) flags: RDW_INVALIDATE RDW_ERASE .. --- snip --- When the start page is closed, the problem goes away. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #4 from Alexandre Julliard <julliard(a)winehq.org> 2008-07-22 06:08:55 --- (In reply to comment #3)
0009:trace:win:GetDCEx (0x10114,0xbb18,0x10080): returning 0x30c 0009:trace:win:BeginPaint hdc = 0x30c box = ((0,0)-(204,59)), fErase = 0 0009:trace:win:WIN_SetWindowLong 0x100d6 0 0 W 0009:trace:win:WIN_SetWindowLong 0x100d6 0 0 W 0009:trace:win:GetDCEx hwnd 0x10114, hrgnClip (nil), flags 00000003 0009:trace:win:GetDCEx found valid 0x12f978 dce [0x10114], flags 00000003 0009:trace:win:GetDCEx (0x10114,(nil),0x3): returning 0x384 0009:trace:win:release_dc 0x10114 0x384 0009:trace:win:RedrawWindow 0x10114 rect (0,0)-(204,66) flags: RDW_INVALIDATE RDW_ERASE
Looks like the window is invalidated again after being painted, so it's normal that it would loop forever. You should try to find out where that RedrawWindow call comes from. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #5 from Anastasius Focht <focht(a)gmx.net> 2008-07-22 16:55:29 --- Created an attachment (id=14991) --> (http://bugs.winehq.org/attachment.cgi?id=14991) Recorded call sequences from window proc (expected behaviour) Hello, there seem to be at least two issues involved here. It's a pain to debug this large app with all its unmanaged and managed code so I sticked with investigating windbg behaviour in hope that's the same issue as VS.NET 2005 Basically the message sequence for the affected window goes like this (5 calls of that winproc): (#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (#3) WM_NCPAINT (#4) WM_NCACTIVATE (active = FALSE) (#5) WM_NCPAINT After that sequence, the window refresh is finished. The info for the affected window (opened via toolbar): --- snip --- Title="Scratch Pad - WinDbg:6.9.0003.113 X86" Parent=00030460 Style=96CD0000 WS_POPUP|WS_MAXIMIZEBOX|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION ExtStyle=00000100 WS_EX_WINDOWEDGE Class=WinBaseClass --- snip --- Parent (top level): --- snip --- Title="WinDbg:6.9.0003.113 X86" Parent=Topmost Style=16CF0000 WS_OVERLAPPED|WS_MINIMIZEBOX|WS_MAXIMIZEBOX|WS_CLIPSIBLINGS|WS_CLIPCHILDREN|WS_VISIBLE|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION ExtStyle=00000110 WS_EX_ACCEPTFILES|WS_EX_WINDOWEDGE Class=WinDbgFrameClass --- snip --- I made note of each user32 call within the app window proc to keep things simple. After comparing both sequences, I noticed the following problem: hRegionClip = NULL; Flags = DCX_WINDOW | DCX_INTERSECTRGN; The call to user32.GetDCEx( hWndScratchWindow, hRegionClip, Flags) returned NULL on Windows XP while Wine returned a valid DC. After further investigation with google it seems this is some sort of undocumented behaviour, see: http://www.virtualdub.org/blog/pivot/entry.php?id=37 --- quote --- As a side note, a poster on the forum recently helped me track down an irritating bug in VirtualDub's draggable video frames that was causing some instability on Win9x platforms. It happened because of a code fragment that I adapted from the MSDN Library documentation for WM_NCPAINT that supposedly helps you draw custom window frames. Well, the code fragment as given doesn't work, because it lacks an essential flag. GetDCEx() simply returns NULL and leaves the error code as NO_ERROR. You need to add 0x10000, called "an undocumented flag which can magically make GetDCEx call succeed" in Feng Yuan's GDI book, or DCX_USESTYLE by WINE, for the function to actually return a usable DC. It turns out that there is an even worse problem with the code as given because it causes window regions to be doubly freed! On Win9x, this results in an occasional crash in 16-bit GDI. (This particular problem with the WM_NCPAINT example is also colorfully documented in comments in the WINE source code.) After I fixed this issue, the poster's problem went away. So if you are using a Win9x platform, expect some stability improvements in edit mode in 1.6.4. --- quote --- I patched dlls/user32/painting.c:GetDCEx for testing purposes but it didn't solve the endless looping problem. The call sequences within that app window proc where GetDCEx was involved were more matching, showing slight improvement over previous situation. It seems the app directly checked for GetDCEx() returning NULL and took that into account (expecting such result). It remains mysterious why a Micro$oft app actually made this call with hard coded flags when it's expected to return NULL? Maybe the people there don't talk to each other/suffer from their own MSDN hell ;-) Maybe some Windows versions show different behaviour? This has to be added to conformance test ... Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #6 from Anastasius Focht <focht(a)gmx.net> 2008-07-22 17:51:56 --- Created an attachment (id=14992) --> (http://bugs.winehq.org/attachment.cgi?id=14992) Recorded call sequences from window proc (wine, endless paint looping) Hello again, attached is the call sequence in Wine for comparison. Note: I didn't use WINEDEBUG but my debugger+scratchpad to keep same style for better comparison (diffing) with previously posted attachment. In short: Wine: (#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (Region = 00000001) (#3) WM_NCACTIVATE (active = FALSE) (#4) WM_NCPAINT (Region = 00000001) .. <repeats forever (same as #4)> .. This is different from previously posted behaviour of app in Windows: (#1) WM_NCACTIVATE (active = TRUE) (#2) WM_NCPAINT (Region = 00000001) (#3) WM_NCPAINT (Region = 0004083B, valid region) (#4) WM_NCACTIVATE (active = FALSE) (#5) WM_NCPAINT (Region = BB040864, valid region) <refresh finished, ends here> Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #7 from Anastasius Focht <focht(a)gmx.net> 2008-07-22 18:19:46 --- Created an attachment (id=14993) --> (http://bugs.winehq.org/attachment.cgi?id=14993) +tid,+seh,+msg,+win,+relay showing endless paint loop problem Hello, attached is full relay (cut to ~24000 lines) showing the problem. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #8 from Anastasius Focht <focht(a)gmx.net> 2008-07-23 01:33:00 --- Created an attachment (id=14999) --> (http://bugs.winehq.org/attachment.cgi?id=14999) callstack each time frame wnd proc is entered Hello, I attached winedbg session of windbg, showing the callstack each time the frame window proc is entered. Sequence is same as described in previous posts. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |0.9.49. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #9 from Austin Lund <austin.lund(a)gmail.com> 2009-06-30 21:17:01 --- Created an attachment (id=22120) --> (http://bugs.winehq.org/attachment.cgi?id=22120) Crazy program to show the behaviour Attached is a program which shows this. In windows it shows the hdc is zero. In wine it is 1e0 (for me). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Austin Lund <austin.lund(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austin.lund(a)gmail.com --- Comment #10 from Austin Lund <austin.lund(a)gmail.com> 2009-07-01 01:18:48 --- The WM_NCPAINT message for this window calls RedrawWindow(hWnd,NULL,NULL,0x441). Would this trigger repainting of everything and hence another WM_NCPAINT message? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #11 from Austin Lund <austin.lund(a)gmail.com> 2009-07-01 02:16:14 --- Created an attachment (id=22121) --> (http://bugs.winehq.org/attachment.cgi?id=22121) Very simple program with identical painting behaviour I've written a program which calls RedrawWindow in WM_NCPAINT in the same way as the windbg program does. It exhibits identical looping behaviour. I haven't tested it on windows to see what it does. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #12 from Austin Lund <austin.lund(a)gmail.com> 2009-07-01 19:52:37 --- I've tested my trial program on WinXPsp2 and the program doesn't do an infinite loop. In wine my test program does: WM_PAINT WM_NCPAINT WM_PAINT WM_NCPAINT WM_NCPAINT WM_PAINT WM_NCPAINT WM_NCPAINT (last 3 messages repeated forever) In my version of XPsp2 it does: WM_NCPAINT WM_NCPAINT WM_PAINT WM_NCPAINT (stops) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #13 from Austin Lund <austin.lund(a)gmail.com> 2009-07-02 00:43:10 --- Created an attachment (id=22138) --> (http://bugs.winehq.org/attachment.cgi?id=22138) Test case It seems that when there is this redraw in the WM_NCPAINT message handler and both the RDW_FRAME and RDW_INVALIDATE flags are set, then there is always an area (the non-client area) that is left flagged as needing to be updated. This patch adds a test for this. On windows after an WM_PAINT message the area needing to be updated is NULL. On wine there is still a region needing to be updated. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #14 from Austin Lund <austin.lund(a)gmail.com> 2009-07-02 23:42:24 --- I think I've found the reason for this. It seems that when wine does BeginPaint() it checks to see if the non-client area is within the update region. When doing this check, the region is validated in that step. If there is a region that needs updating a WM_NCPAINT message is sent. In this case the RedrawWindow() function will invalidate the whole thing. There is nowhere else that this can become valid. And hence at EndPaint() things are still marked as invalid. Then a WM_PAINT message is added and things go round again. To explain this I've tried to do some psuedocode of what happens on wine and windows: Wine: WndProc WM_PAINT DefWndProc(WM_PAINT) BeginPaint() send_ncpaint() get_update_region() // Region Validated ... SendMessageW(WM_NCPAINT) WndProc WM_NCPAINT RedrawWindow() // Invalidates window DefWndProc(WM_NCPAINT) // Still invalid ... EndPaint() // Still Invaid As the window is marked invalid It calls WM_PAINT again. Windows: WndProc WM_PAINT DefWndProc(WM_PAINT) BeginPaint() FindUpdateRegion() // Does not validate region SendMessageW(WM_NCPAINT) // Still region invalid WndProc WM_NCPAINT RedrawWindow() // Region still invalid so does not matter DefWndProc(WM_NCPAINT) // Still Invalid ... // Painting instructions ValidateUpdateRegion() // Finally Validated Update Region ... EndPaint() // Region fully validated Nothing marked as invalid! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #15 from Austin Lund <austin.lund(a)gmail.com> 2009-07-09 00:59:10 --- There seem to be two confounding effects here. a) When DispatchMessage() is called on a WM_PAINT message in wine, the WNDPROC is called and then _after_ it has done what it does, if parts of the window are still marked as invalid they are updated using GetUpdateRgn(..,..,TRUE). This doesn't seem to happen in windows. The WM_NCPAINT and WM_ERASEBACKGROUND messages seem to be processed in a WM_PAINT message _before_ the WNDPROC is called. b) When BeginPaint() is called and a WM_NCPAINT message is processed within it, the window is marked as invalid in wine when BeginPaint() returns. In windows a BeginPaint() seems to mark everything as clean even if WM_NCPAINT called RedrawWindow(..,..,..,0x401). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Volodymyr Shcherbyna <volodymyr(a)shcherbyna.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #16 from Volodymyr Shcherbyna <volodymyr(a)shcherbyna.com> 2009-07-15 16:28:47 --- *** This bug has been confirmed by popular vote. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #22138|0 |1 is obsolete| | --- Comment #17 from Austin English <austinenglish(a)gmail.com> 2010-04-30 15:03:03 --- (From update of attachment 22138) Testcase is in wine: http://source.winehq.org/git/wine.git/?a=commitdiff;h=65758cde7f8a131f7bdc16... and still a todo_wine, so not fixed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #18 from Austin Lund <austin.lund(a)gmail.com> 2010-08-15 01:47:12 --- (In reply to comment #15)
b) When BeginPaint() is called and a WM_NCPAINT message is processed within it, the window is marked as invalid in wine when BeginPaint() returns. In windows a BeginPaint() seems to mark everything as clean even if WM_NCPAINT called RedrawWindow(..,..,..,0x401).
On further investigation, this seems to be the more important part. BeginPaint() should leave the whole thing validated even under the conditions for this bug. This means that the validation should occur AFTER all the other window messages are sent and processed (such as WM_NCPAINT in this case). Currently it happens with a call of get_update_region to the wineserver before any of the messages are sent. Reversing this is probably the key. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh(a)gmail.com --- Comment #19 from Jerome Leclanche <adys.wh(a)gmail.com> 2010-09-03 16:51:15 CDT --- Bug 17088 is likely a duplicate of this bug. Could someone check? The app is affected by the infinite loop, but I have no idea if it would cause the issues described there. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #20 from Jerome Leclanche <adys.wh(a)gmail.com> 2010-09-18 16:26:01 CDT --- *** Bug 17088 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Thomas Spear <Speeddymon(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Speeddymon(a)gmail.com --- Comment #21 from Thomas Spear <Speeddymon(a)gmail.com> 2010-09-18 16:35:16 CDT --- (In reply to comment #20)
*** Bug 17088 has been marked as a duplicate of this bug. ***
Bug 17088 does not result in 100% cpu (not even on 1 core), that I have ever noticed when I've encountered it personally. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #22 from Jerome Leclanche <adys.wh(a)gmail.com> 2010-09-18 16:35:53 CDT --- (In reply to comment #21)
(In reply to comment #20)
*** Bug 17088 has been marked as a duplicate of this bug. ***
Bug 17088 does not result in 100% cpu (not even on 1 core), that I have ever noticed when I've encountered it personally.
Certainly does here. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #23 from Thomas Spear <Speeddymon(a)gmail.com> 2010-09-18 16:39:37 CDT --- Strange indeed. I don't have WoW installed at the moment, but I probably should for testing things like this. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #24 from Jerome Leclanche <adys.wh(a)gmail.com> 2010-09-18 17:50:41 CDT --- (In reply to comment #23)
Strange indeed.
I don't have WoW installed at the moment, but I probably should for testing things like this.
The WoW trial client should suffice for testing this. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dank(a)kegel.com --- Comment #25 from Dan Kegel <dank(a)kegel.com> 2010-09-18 20:10:49 CDT --- Wait, how do you reproduce this with WoW? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #26 from Dan Kegel <dank(a)kegel.com> 2010-09-18 20:12:32 CDT --- Oh, never mind, I read bug 17088 now. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Devin Cofer <ranguvar(a)archlinux.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ranguvar(a)archlinux.us -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #27 from Jerome Leclanche <adys.wh(a)gmail.com> 2011-10-25 16:50:50 CDT --- Still an issue in wine-1.3.31-58-g8994db9. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|endless WM_PAINT loop bug |Multiple applications |(update regions, queue |encounter infinite WM_PAINT |paint count) |loop (Platform SDK tools, | |World of Warcraft Launcher) --- Comment #28 from Anastasius Focht <focht(a)gmx.net> 2012-01-22 14:28:08 CST --- Hello, still present and found another app that suffers from this, constantly doing region (re)paint, eating one CPU. "FileTypeVerifier" from Windows Platform SDK 7.1. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Microsoft SDKs/Windows/v7.1/Bin ... $ wine ./FileTypeVerifier.exe --- snip --- --- snip --- Wine-dbg>bt Backtrace: =>0 0x68001292 _dl_sysinfo_int80+0x2() in ld-linux.so.2 (0x0033f8b4) 1 0x6802e91e pthread_sigmask+0x4d() in libpthread.so.0 (0x0033f8b4) 2 0x7bc75131 wine_server_call+0x7a(req_ptr=0x33f8d0) [/home/focht/projects/wine/wine-git/dlls/ntdll/server.c:290] in ntdll (0x0033f8b4) 3 0x683d6f15 get_update_region+0x112(hwnd=0x10070, flags=0x33fa10, child=(nil)) [/home/focht/projects/wine/wine-git/dlls/user32/painting.c:547] in user32 (0x0033f984) 4 0x683d71b9 send_ncpaint+0x2a(hwnd=0x10070, child=(nil), flags=0x33fa10) [/home/focht/projects/wine/wine-git/dlls/user32/painting.c:626] in user32 (0x0033f9e4) 5 0x683d86e0 GetUpdateRgn+0x3c(hwnd=0x10070, hrgn=0xaa08, erase=0x1) [/home/focht/projects/wine/wine-git/dlls/user32/painting.c:1297] in user32 (0x0033fa24) 6 0x683cc987 DispatchMessageW+0x249(msg=0x33fbb8) [/home/focht/projects/wine/wine-git/dlls/user32/message.c:3838] in user32 (0x0033fb34) 7 0x6838bc9b IsDialogMessageW+0x6d4(hwndDlg=0x2002a, msg=0x33fbb8) [/home/focht/projects/wine/wine-git/dlls/user32/dialog.c:1313] in user32 (0x0033fb94) 8 0x73c46e25 do_loop+0x32(psInfo=0x137ff0) [/home/focht/projects/wine/wine-git/dlls/comctl32/propsheet.c:2732] in comctl32 (0x0033fbe4) 9 0x73c46fd6 PROPSHEET_PropertySheet+0xfb(psInfo=0x137ff0, unicode=0x1) [/home/focht/projects/wine/wine-git/dlls/comctl32/propsheet.c:2775] in comctl32 (0x0033fc24) 10 0x73c473e1 PropertySheetW+0x1ec(lppsh=0x33fd04) [/home/focht/projects/wine/wine-git/dlls/comctl32/propsheet.c:2868] in comctl32 (0x0033fc84) 11 0x01011463 in filetypeverifier (+0x11462) (0x0033fd80) 12 0x010114ca in filetypeverifier (+0x114c9) (0x0033fdac) 13 0x010121ba in filetypeverifier (+0x121b9) (0x0033fe40) --- snip --- Download SDK: http://www.microsoft.com/download/en/details.aspx?id=8279 (SDK 7.1 installer needs .NET 4.0 Framework prerequisite installed) $ sha1sum winsdk_web.exe a8717ebb20a69c7efa85232bcb9899b8b07f98cf winsdk_web.exe $ wine --version wine-1.3.37-254-g14b790a Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #29 from Jerome Leclanche <adys.wh(a)gmail.com> 2013-04-20 14:43:42 CDT --- No longer reproducible using the wow launcher, as it's been rewritten. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10522 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.microsoft.com/wh |http://msdn.microsoft.com/e |dc/devtools/debugging/insta |n-US/windows/hardware/gg463 |llx86.mspx |009/ Summary|Multiple applications |Multiple applications |encounter infinite WM_PAINT |encounter infinite WM_PAINT |loop (Platform SDK tools, |loop (Platform SDK tools) |World of Warcraft Launcher) | --- Comment #30 from Anastasius Focht <focht(a)gmx.net> 2013-04-21 14:09:39 CDT --- Hello Jerome, --- quote --- No longer reproducible using the wow launcher, as it's been rewritten. --- quote --- Ok, removing the game from summary then. The bug is obviously still present with other apps (Windows SDK). $ wine --version wine-1.5.28-133-g7d8f3a1 Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #31 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, still present. $ wine --version wine-1.7.40-29-gc1c108f Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10522 Sylvain Petreolle <spetreolle(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle(a)yahoo.fr -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10522 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #32 from joaopa <jeremielapuree(a)yahoo.fr> --- Does the bug still occur with wine-4.0-rc7? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #33 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, still present. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files (x86)/Debugging Tools for Windows (x86) $ WINEDLLOVERRIDES=dbgeng=n wine ./windbg.exe ... --- snip --- $ wine --version wine-4.0-276-g84459ba94b Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #34 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, still present. Adding stable download links to 'Debugging Tools for Windows 6.12.x' via Internet Archive. They don't require Windows SDK installation (https://web.archive.org/web/20130131051038/http://www.microsoft.com/en-us/do...) 32-bit: https://web.archive.org/web/20190317014512/http://download.microsoft.com/dow... $ sha1sum dbg_x86.msi 117814c255f19dc67e769c668bc97e547c05a55b dbg_x86.msi $ du -sh dbg_x86.msi 19M dbg_x86.msi 64-bit: https://web.archive.org/web/20190317014905/http://download.microsoft.com/dow... $ sha1sum dbg_amd64.msi 257978e5dc64ae8f8e2b591bd9c147178117d235 dbg_amd64.msi $ du -sh dbg_amd64.msi 17M dbg_amd64.msi $ wine --version wine-6.14-250-gcaf5ab5d65e Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10522 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://msdn.microsoft.com/e |https://web.archive.org/web |n-US/windows/hardware/gg463 |/20190317014512/http://down |009/ |load.microsoft.com/download | |/A/6/A/A6AC035D-DA3F-4F0C-A | |DA4-37C8E5D34E3D/setup/WinS | |DKDebuggingTools/dbg_x86.ms | |i -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #35 from joaopa <jeremielapuree(a)yahoo.fr> --- Does the bug still occur with wine-20.1? I could test by myself (there is a download) but I do not understand what the bug is about. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=10522 --- Comment #36 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, obviously still present. Retested with 64-bit Debugging Tools for Windows 6.12.x. Just open a command window or any other tool window and see one cpu core being hogged 100%. $ wine --version wine-10.1-125-g4de56399442 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla