Hello,
Seems that lately, as soon as I press a key in the debugger, it segfaults and starts another debugger ... which will also segtault ... und so weiter.
So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it works) but how do I know which symbols to load (winedbg being a script, wine having no code except linking to DLLs, ....) ?
Lionel
Lionel Ulmer wrote:
Hello,
Seems that lately, as soon as I press a key in the debugger, it segfaults and starts another debugger ... which will also segtault ... und so weiter.
So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it works) but how do I know which symbols to load (winedbg being a script, wine having no code except linking to DLLs, ....) ?
Lionel
I have the same problem when debugging a certain program (dink smallwood) but not with others. Debugging winzip does not have this problem. the problem started at least a week ago but I have not had time to do a regression set on it.
So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it works) but how do I know which symbols to load (winedbg being a script, wine having no code except linking to DLLs, ....) ?
load miscemu/wine in gdb, it'll get what you're looking for
if it doesn't work better you can also try the attached patch (if the bug is triggered inside the debugger, otherwise - in some builtin DLLs, or in wineconsole - it won't help at all)
A+
On Sat, Dec 21, 2002 at 05:49:23PM +0100, Eric Pouech wrote:
So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it works) but how do I know which symbols to load (winedbg being a script, wine having no code except linking to DLLs, ....) ?
load miscemu/wine in gdb, it'll get what you're looking for
OK, what happens is that the application is loading the DINPUT library... And at DLL load time, it adds a low-level hook for the keyboard (I wonder why only for the keyboard and not the mouse, but well, that's another problem :-) ).
And it seems that the invocation of this hook from the wineconsole makes Wine crash. I think that the problem is that the DLL is loaded from the application's context and called from the console context.
Now, one could do the same for the mouse, ie install the hook only later on when acquiring the keyboard, but well, I think the problem would be the same if the debugger is started after the 'acquire'.
So I wonder how to 'fix' this... I think I know Eric's answer : use GDB's proxy stuff and debug Wine using a non-Wine application :-)
Lionel
Lionel Ulmer lionel.ulmer@free.fr writes:
And it seems that the invocation of this hook from the wineconsole makes Wine crash. I think that the problem is that the DLL is loaded from the application's context and called from the console context.
The problem is that system hooks don't work so well in builtin dlls because the load address is not always aligned. For the low-level keyboard and mouse hooks it shouldn't matter because they should always be called in the context of the process that set the hook, but this is not implemented yet. There's the same problem with the journalling hooks, I'm working on it.
Now, one could do the same for the mouse, ie install the hook only later on when acquiring the keyboard, but well, I think the problem would be the same if the debugger is started after the 'acquire'.
We should definitely do that in any case. Having the keyboard hook set even when not needed will be a serious performance hit.
On Sat, 21 Dec 2002, Lionel Ulmer wrote:
On Sat, Dec 21, 2002 at 05:49:23PM +0100, Eric Pouech wrote:
So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it works) but how do I know which symbols to load (winedbg being a script, wine having no code except linking to DLLs, ....) ?
load miscemu/wine in gdb, it'll get what you're looking for
OK, what happens is that the application is loading the DINPUT library... And at DLL load time, it adds a low-level hook for the keyboard (I wonder why only for the keyboard and not the mouse, but well, that's another problem :-) ).
And it seems that the invocation of this hook from the wineconsole makes Wine crash. I think that the problem is that the DLL is loaded from the application's context and called from the console context.
Now, one could do the same for the mouse, ie install the hook only later on when acquiring the keyboard,
Or when creating the device (since Arjen Nienhuis made it hook on startup because some app used GetDeviceState without acquiring the device), like in this WineX patch I just wrote to fix a game that didn't like the dinput hook to be installed before its own keyboard hook:
Index: dinput_main.c =================================================================== RCS file: /cvsroot/winex/wine/dlls/dinput/dinput_main.c,v retrieving revision 1.18 diff -u -r1.18 dinput_main.c --- dinput_main.c 25 Sep 2002 20:23:15 -0000 1.18 +++ dinput_main.c 22 Dec 2002 14:52:02 -0000 @@ -43,10 +43,8 @@ switch(reason) { case DLL_PROCESS_ATTACH: - keyboard_hook = SetWindowsHookExW( WH_KEYBOARD_LL, KeyboardCallback, 0, 0 ); break; case DLL_PROCESS_DETACH: - UnhookWindowsHookEx(keyboard_hook); break; } return TRUE; Index: dinput_private.h =================================================================== RCS file: /cvsroot/winex/wine/dlls/dinput/dinput_private.h,v retrieving revision 1.8 diff -u -r1.8 dinput_private.h --- dinput_private.h 5 Sep 2002 11:52:43 -0000 1.8 +++ dinput_private.h 22 Dec 2002 14:52:02 -0000 @@ -26,10 +26,6 @@
extern void dinput_register_device(dinput_device *device) ;
-HHOOK keyboard_hook; - -LRESULT CALLBACK KeyboardCallback( int code, WPARAM wparam, LPARAM lparam ); - HRESULT DeviceThunkA_create_device(dinput_device* device, IDirectInputImpl* dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev); HRESULT DeviceThunkW_create_device(dinput_device* device, IDirectInputImpl* dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEW* pdev); HRESULT DeviceThunkA_enum_device(dinput_device* device, DWORD dwDevType, DWORD dwFlags, LPDIDEVICEINSTANCEA lpddi); Index: keyboard/main.c =================================================================== RCS file: /cvsroot/winex/wine/dlls/dinput/keyboard/main.c,v retrieving revision 1.16 diff -u -r1.16 main.c --- keyboard/main.c 25 Sep 2002 20:23:15 -0000 1.16 +++ keyboard/main.c 22 Dec 2002 14:52:02 -0000 @@ -59,6 +59,8 @@
static BYTE DInputKeyState[256]; /* array for 'GetDeviceState' */
+CRITICAL_SECTION keyboard_crit = CRITICAL_SECTION_INIT("dinput_keyboard"); +DWORD keyboard_users; HHOOK keyboard_hook;
LRESULT CALLBACK KeyboardCallback( int code, WPARAM wparam, LPARAM lparam ) @@ -147,6 +149,11 @@ memcpy(&(newDevice->guid),rguid,sizeof(*rguid)); newDevice->dinput = dinput;
+ EnterCriticalSection(&keyboard_crit); + if (!keyboard_users++) + keyboard_hook = SetWindowsHookExW( WH_KEYBOARD_LL, KeyboardCallback, 0, 0 ); + LeaveCriticalSection(&keyboard_crit); + return newDevice; }
@@ -179,6 +186,31 @@
DECL_GLOBAL_CONSTRUCTOR(keyboarddev_register) { dinput_register_device(&keyboarddev); }
+static ULONG WINAPI SysKeyboardAImpl_Release(LPDIRECTINPUTDEVICE8A iface) +{ + ICOM_THIS(SysKeyboardAImpl,iface); + + This->ref--; + if (This->ref) + return This->ref; + + EnterCriticalSection(&keyboard_crit); + if (!--keyboard_users) { + UnhookWindowsHookEx( keyboard_hook ); + keyboard_hook = 0; + } + LeaveCriticalSection(&keyboard_crit); + + /* Free the data queue */ + if (This->buffer != NULL) + HeapFree(GetProcessHeap(),0,This->buffer); + + DeleteCriticalSection(&(This->crit)); + + HeapFree(GetProcessHeap(),0,This); + return 0; +} + static HRESULT WINAPI SysKeyboardAImpl_SetProperty( LPDIRECTINPUTDEVICE8A iface,REFGUID rguid,LPCDIPROPHEADER ph ) @@ -381,7 +413,7 @@ ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE IDirectInputDevice2AImpl_QueryInterface, IDirectInputDevice2AImpl_AddRef, - IDirectInputDevice2AImpl_Release, + SysKeyboardAImpl_Release, SysKeyboardAImpl_GetCapabilities, IDirectInputDevice2AImpl_EnumObjects, IDirectInputDevice2AImpl_GetProperty,
-
Alexandre Julliard -
Eric Pouech -
Lionel Ulmer -
Ove Kaaven -
Tony Lambregts