possibly new regression

[MightY]

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

[Rein Klazes]

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

[Sebastian Schlingmann]

On Sun, 20 Feb 2005 16:04:54 +0100
Rein Klazes  wrote:
> Does this patch help?
>
> Rein.

Unfortunately not - still the exact same error.

[Rein Klazes]

On Sun, 20 Feb 2005 16:41:09 +0100, you wrote:
> On Sun, 20 Feb 2005 16:04:54 +0100
> Rein Klazes  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.

[Sebastian Schlingmann]

On Mon, 21 Feb 2005 21:49:32 +0100
Rein Klazes  wrote:
> On Sun, 20 Feb 2005 16:41:09 +0100, you wrote:
> > On Sun, 20 Feb 2005 16:04:54 +0100
> > Rein Klazes  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.