[Bug 1165] Photoshop6 hangs, can potentially lock X server, and machine.
http://bugs.winehq.com/show_bug.cgi?id=1165 ------- Additional Comments From 7ownq0k402(a)sneakemail.com 2003-22-06 11:31 ------- Recovered from news.gmane.org: http://bugs.winehq.com/show_bug.cgi?id=1165 Summary: Photoshop6 hangs, can potentially lock X server, and machine. Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.com ReportedBy: 7ownq0k402(a)sneakemail.com Wine build: Build 20021031 (Not in version list) Steps to reproduce: 1. Run Photoshop6 2. Photoshop starts running. 3. Photoshop main window comes up (sometimes badly drawn) 4. The splash screen comes up. 5. Towards the end of the load ("Initialising..." is in splash screen) the main window disappears, as does the splash screen. 6. The whole screen is now locked apart from the KDE panel, with the cursor showing the hourglass. 7. When menus are lauched from the panel. the mouse works properly in menu. Menu is draw correctly, but when leave menu, nothing is re-drawn. 8. Sometimes (especially if left in locked state) Photoshop 6 will use all available memory (real & swap), and linux will hang. Repeatability: Always. Workarounds attempted (None succeded): 1. Attempted using the following DLLs native: shell,shell32,commtrl,comctl32,commdlg,comdlg32,shlwapi, ole32,rpcrt4,shlwapi,oleaut32,msvcrt20,msvcrt,msvcp60,shfolder 2. Removed the native wintab32.dll 3. Tried with "Synchronous" = "Y" This improved the drawing, but didn't fix the bug. 4. Tried with OS set to Win 98. Wine config: Is based upon a win98 install. Photoshop6 was installed in Win98. Options for exiting lock: 1. Go to a console (CTRL-ALT-FNKEY), and kill wineserver, and any wine apps. 2. Shutdown computer (sometimes possible from KDE panel menu. 3. Reset computer. Looks almost as if a X grab has occured, on the whole screen apart from the KDE panel. I am happy to provide debug reports, but I'll need guidance as to how to proceed, because all debug logs I've created are large, and Photoshop must run at a reasonable rate so I can kill it before Something to do with shfolder.dll????? Seems to occur near wher dll is loaded. ------- Additional Comments From 7ownq0k402(a)sneakemail.com 2002-11-27 06:40 ------- In the bug report, I didn't complete this paragraph: I am happy to provide debug reports, but I'll need guidance as to how to proceed, because all debug logs I've created are large, and Photoshop must run at a reasonable rate so I can kill it before it consumes all memory. ------- Additional Comments From 7ownq0k402(a)sneakemail.com 2002-11-27 10:57 ------- Looking closely, the Window Manager controlled parts of the window disappear too. This suggests some foulup relating to X11 communication, as the area is obviously grabbed, but there's not title bar to minimise the grabbed window with. ------- Additional Comments From 7ownq0k402(a)sneakemail.com 2002-11-27 14:10 ------- It turns out that Photoshop removes all top level windows from the KDE panel. ------- Additional Comments From 7ownq0k402(a)sneakemail.com 2002-11-28 10:23 ------- Did some serious gdb debugging on the problem. Conclusion: This is an X11driver problem, moving to x11driver component Motes on the debug session follows: The problem occurs as 1st wine processs exits with error code 1. After this the wineserver process (and possibly another wine process seem to go mad). They cause 100% kernel load, and 100% use of swap. did breakpoint on exit() in gdb wine, on the 1st process (desktop???) got following stack trace #0 0x402761dd in exit () from /lib/libc.so.6 #1 0x4106913a in _XDefaultError () from /usr/X11R6/lib/libX11.so.6 #2 0x40ff66bd in error_handler (display=0x80a0e08, error_evt=0x406d18a4) at x11drv_main.c:136 #3 0x4106924d in _XError () from /usr/X11R6/lib/libX11.so.6 #4 0x4106787b in _XReply () from /usr/X11R6/lib/libX11.so.6 #5 0x4106319a in XSync () from /usr/X11R6/lib/libX11.so.6 #6 0x40fef7c4 in TSXSync (a0=0x80a0e08, a1=0) at ts_xlib.c:614 #7 0x40ff148f in X11DRV_CreateWindow (hwnd=0x10051, cs=0x406d1c00, unicode=0) at window.c:893 #8 0x4086c1d0 in WIN_CreateWindowEx (cs=0x406d1c00, classAtom=49155, type=WIN_PROC_32A) at ../../windows/win.c:1166 #9 0x4086c63b in CreateWindowExA (exStyle=0, className=0x10156c0 "edit", windowName=0x10974a4 "", style=1073807488, x=5, y=6, width=101, height=16, parent=0x10026, menu=0x177b, instance=0x400000, data=0x0) at ../../windows/win.c:1320 The contents of error_evt was: (gdb) print error_evt $1 = (XErrorEvent *) 0x406d18a4 (gdb) print error_evt->type $2 = 0 (gdb) print error_evt->display $3 = (Display *) 0x80a0e08 (gdb) print error_evt->resourceid $4 = 77594636 (gdb) print error_evt->serial $5 = 911 (gdb) print error_evt->error_code $6 = 8 '\b' (gdb) print error_evt->request_code $7 = 7 '\a' (gdb) print error_evt->minor_code $8 = 0 '\000' And what's the error: (gdb) call XGetErrorText(display,error_evt->error_code,1076119904,1000) $15 = 0 (gdb) print (char*)(1076119904) $16 = 0x40244960 "BadMatch (invalid parameter attributes)" ------- Additional Comments From marcus(a)jet.franken.de 2002-11-28 15:01 ------- set the "Synchronous" flag to "Yes" and run again. this will pop up the debugger on fault and will show the real x instruction which did hang. ------- Additional Comments From 7ownq0k402(a)sneakemail.com 2002-11-28 19:00 ------- Here's the stack backtrace from the synchronous mode. Oh, all my traces are done with "Desktop" = "800x600". Synchronous backtrace: (gdb) bt #0 0x40770f34 in DebugBreak () at ../../include/winternl.h:808 #1 0x40ff66b3 in error_handler (display=0x80a0e08, error_evt=0x406d16c8) at x11drv_main.c:135 #2 0x4106924d in _XError () from /usr/X11R6/lib/libX11.so.6 #3 0x4106787b in _XReply () from /usr/X11R6/lib/libX11.so.6 #4 0x4106319a in XSync () from /usr/X11R6/lib/libX11.so.6 #5 0x41063234 in _XSyncFunction () from /usr/X11R6/lib/libX11.so.6 #6 0x41060dd9 in XReparentWindow () from /usr/X11R6/lib/libX11.so.6 #7 0x40ff1bea in X11DRV_SetParent (hwnd=0x10021, parent=0x10026) at window.c:1118 #8 0x4086e5cb in SetParent (hwnd=0x10021, parent=0x10026) at ../../windows/win.c:2557 #9 0x40888cf7 in handle_internal_message (hwnd=0x10021, msg=2147483651, wparam=65574, lparam=0) at message.c:1057 #10 0x40889531 in call_window_proc (hwnd=0x10021, msg=2147483651, wparam=65574, lparam=0, unicode=1, same_thread=1) at message.c:1355 #11 0x4088a12f in SendMessageTimeoutW (hwnd=0x10021, msg=2147483651, wparam=65574, lparam=0, flags=0, timeout=4294967295, res_ptr=0x0) at message.c:1737 #12 0x40886ef4 in broadcast_message_callback (hwnd=0x10021, lparam=1080891832) at message.c:298 #13 0x4086ee72 in EnumWindows ( lpEnumFunc=0x40886e70 <broadcast_message_callback>, lParam=1080891832) ---Type <return> to continue, or q <return> to quit--- at ../../windows/win.c:2957 #14 0x4088a0b8 in SendMessageTimeoutW (hwnd=0xffffffff, msg=2147483651, wparam=65574, lparam=0, flags=0, timeout=4294967295, res_ptr=0x406d1a0c) at message.c:1724 #15 0x4088a3b9 in SendMessageW (hwnd=0xffffffff, msg=2147483651, wparam=65574, lparam=0) at message.c:1818 #16 0x4086e5b0 in SetParent (hwnd=0xffffffff, parent=0x10026) at ../../windows/win.c:2552 Also from a trace of the server log when running asynchonous gives: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 7 (X_ReparentWindow) Serial number of failed request: 911 Current serial number in output stream: 918 So it's the ReparentWindow that fails, and from documentation, will fail with BadMatch if: *The new parent window is not on the same screen as the old parent window. *The new parent window is the specified window or an inferior of the specified window. *The new parent is InputOnly, and the window is not. *The specified window has a ParentRelative background, and the new parent window is not the same depth as the specified window. ------- Additional Comments From 7ownq0k402(a)sneakemail.com 2002-12-06 11:16 ------- More info: **** On the SetParentCall failure **** The call to SetParent is SetParent(HWND_BROADCAST,A_Window) So, it looks as if it attempts to broadcast this to all top level windows. Don't know what Windows does, but I'm certain it shouldn't fail as badly as it does. My suggestion: Handle the "Bad Match" error, and return an error result to the calling app (If possible). To fix this properly, need a test for the behaviour on Windows. *** On the hang **** I suspect that Wine shouldn't (in theory) hang on an error like this. I suspect it does hang because because it's attempting to open the debugger, while some of it's windows are mangled. Will test disabling the bebugger in wine config. -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
participants (1)
-
Wine Bugs