RE: Any advice on how to debug this?

[Medland, Bill]

> -----Original Message-----
> From: Eric Pouech [mailto:[e-mail]]
> Sent: Wednesday, July 10, 2002 4:59 AM
> To: Medland, Bill
> Cc: Wine devel (E-mail)
> Subject: Re: Any advice on how to debug this?
> > The stack traces in both cases are similar and indicate to
>
> me that the
> > processes have ended up executing data.
> > However by the time I get to disassemble the code referred to by the
> > backtrace the code isn't there any longer.
>
> is most of the cases, it means that the program is no longer 
> running (it
> may 
> have been killed by the other program)
> > What's my best bet for tracking this down?
>
> as the processes seem to be furtive, using relay traces (and friends)
> may be
> a better bet to locate the issue, and then perhaps set the bp where
> needed
>
> A+

Thanks Eric.

So now what do we do.

Having messed about, got a repeatable case and generally bashed my head
around I have got to the following unfortunate situation.

It looks to me like:

comctl32.dll includes a shared data segment.
One of the entries in that segment, presumably during the DllEntry, is
populated with the address of GetSystemMetrics

A second copy of comctl32 then tries to use that address to call
GetSystemMetrics

Unfortunately the second process has user32 mapped somewhere else and so the
call goes somewhere weird and things fall over.

Any ideas as to what we can do about it?

Bill

Any advice on how to debug this?

[Alexandre Julliard]

"Medland, Bill"  writes:
> It looks to me like:
>
> comctl32.dll includes a shared data segment.
> One of the entries in that segment, presumably during the DllEntry, is
> populated with the address of GetSystemMetrics
>
> A second copy of comctl32 then tries to use that address to call
> GetSystemMetrics
>
> Unfortunately the second process has user32 mapped somewhere else and so the
> call goes somewhere weird and things fall over.
>
> Any ideas as to what we can do about it?

That's a common problem with Win9x dlls. It cannot be completely fixed
because we don't control the layout of our address space; there are
some hacks that could be done in the loader to make it less likely to
happen, but I'm not convinced it is worth the trouble. Our efforts
would probably be better spent making sure the builtin versions of the
offending dlls work properly.