Hi, I'm new to the list, so please tell me if I do anything wrong ;). The update from wine-2005-01-11 to wine-2005-02-11 caused a regression with an application I'm trying to get to work. I identified the concrete patch that introduces the problem. It's this one made by Rein Klazes: http://www.winehq.org/hypermail/wine-cvs/2005/01/0612.html What I see happening is the following: sebi(a)mighty system $ wine gothic.exe wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: divide by zero in 32-bit code (0x00500280). In 32 bit mode. err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:00500280 ESP:7785fcdc EBP:7785fe1c EFLAGS:00010246( - 00 -RIZP1) EAX:5da7c456 EBX:00000000 ECX:7785fe14 EDX:01c516a3 ESI:77b13480 EDI:76e166c0 Stack dump: 0x7785fcdc: 77bf19fb 77bf19fa 00000000 6b636f4c 0x7785fcec: 544f475f 00434948 758a00b0 77b07720 0x7785fcfc: 7599ef50 00890668 0a93c21c 00000000 0x7785fd0c: 7785fe14 0a93c31a 7599ef50 0055d8da 0x7785fd1c: 7599ef50 004012b2 7599ef50 0000c028 0x7785fd2c: 0044cb88 77bf19fb 77bf19fa 007f56ec Backtrace: =>1 0x00500280 in gothic (+0x100280) (0x7785fe1c) 2 0x00500121 in gothic (+0x100121) (0x7785fe58) 3 0x0050005c in gothic (+0x10005c) (0x007f56ec) 4 0x0080b1d8 in gothic (+0x40b1d8) (0x0041daf0) 0x00500280: divl 0x00895c58,%eax Wine-dbg> No window is drawn (usually a splash screen appears...). Maybe you can make some sense of it. Surely I didn't provide a lot of information, but I'm not really sure what kind of info you will need. If you need any additional information on the problem, please tell me. -- Sebastian Schlingmann
On Sat, 19 Feb 2005 17:56:45 +0100, you wrote:
Hi,
I'm new to the list, so please tell me if I do anything wrong ;).
The update from wine-2005-01-11 to wine-2005-02-11 caused a regression with an application I'm trying to get to work.
I identified the concrete patch that introduces the problem.
It's this one made by Rein Klazes: http://www.winehq.org/hypermail/wine-cvs/2005/01/0612.html
What I see happening is the following:
sebi(a)mighty system $ wine gothic.exe wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: divide by zero in 32-bit code (0x00500280). [snip]
Does this patch help? Rein.
On Sun, 20 Feb 2005 16:41:09 +0100, you wrote:
On Sun, 20 Feb 2005 16:04:54 +0100 Rein Klazes <wijn(a)wanadoo.nl> wrote:
Does this patch help?
Rein.
Unfortunately not - still the exact same error.
Surprise :( OK, I can try once more, perhaps the counter is much more then the program expects (it resets when windows is restarted, here it counts up from 1970/1/1). Try attached patch (first reverse previous patch, them make; make install and test again) Then if it does not work. As the patch fixes a real problem, reverting is not an option. You will need to debug this to find out why the crash happens. If you run this with WINEDEBUG=+relay, can you look for both QueryPerformanceCounter or QueryPerformanceFrequency in the lines just before the crash? With some luck the addresses of the call (look at ret=......) is near where the crash happens ( it is reported by the debugger: 0x00500280) and we can look at the disassembled code (debugger command "disass adr1, addr2"). Rein.
On Mon, 21 Feb 2005 21:49:32 +0100 Rein Klazes <wijn(a)wanadoo.nl> wrote:
On Sun, 20 Feb 2005 16:41:09 +0100, you wrote:
On Sun, 20 Feb 2005 16:04:54 +0100 Rein Klazes <wijn(a)wanadoo.nl> wrote:
Does this patch help?
Rein.
Unfortunately not - still the exact same error.
Surprise :(
OK, I can try once more, perhaps the counter is much more then the program expects (it resets when windows is restarted, here it counts up from 1970/1/1). Try attached patch (first reverse previous patch, them make; make install and test again)
Then if it does not work. As the patch fixes a real problem, reverting is not an option. You will need to debug this to find out why the crash happens.
If you run this with WINEDEBUG=+relay, can you look for both QueryPerformanceCounter or QueryPerformanceFrequency in the lines just before the crash?
With some luck the addresses of the call (look at ret=......) is near where the crash happens ( it is reported by the debugger: 0x00500280) and we can look at the disassembled code (debugger command "disass adr1, addr2").
Rein.
Thanks a lot! That did it. Everything is back to normal again. -- Sebastian Schlingmann
participants (3)
-
MightY -
Rein Klazes -
Sebastian Schlingmann