Corrupted file problem Wine20040613,20040505 with Xilinx XST 6.2i

[Rein Klazes]

On Wed, 16 Jun 2004 20:56:58 +0200, you wrote:

> On Wednesday 16 June 2004 08:56, Rein Klazes wrote:
> > The source tree from which you compiled has to be reachable under one of
> > wine's configured Drive's. I normally open the source in an editor.
> 
> Didn't work !?  Still gives at startup: Unable to open file /winternl.h

Something here. When it hits a breakpoint the file is found though. I
cannot can it to list code though, part of the current winedbg breakage
I think.

> 
> I call it like this: ~/Software/Wine/wine/wine winedbg  xst.exe -intstyle ise 
> -ifn __projnav/stopwatch.xst -ofn stopwatch.syr
> 
> When I set breakpoints, I get a lot of messages like this:
> [...]
> fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: 
> module.0<40529348-00000004> module<40529348-00000000>
> fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: 
> iDateW.4<40509aba-0000000c> iDateW<40509aba-00000000>
> [...]

This is discussed on the developer list, subject "Debugger spews
elf_new_wine_thunks fixmes". You are hitting bugs in the debugger, it
seems a good idea you send you questions to the developer list as it is 
such a specialized item.

[snip]

> Yepp - normally the program in this configuration runs about 10sec. With 
> +file,+ntdll and additionally +relay it run now +10h and still wasn't 
> through! It created a 4MB bzip2'ed log-file. This could be 100gig or more
>  uncompressed. +relay apparently creates a lot of output and bzip2 consumes
>  90% cpu to compress it.

What I meant to say was that as a start +relay is good enough.
Additional +file,+ntdll can be added later if you know what to look for.

> 
> I have extracted some hopefully good parts. There are things like CreateFile 
> and some steps after the same file is deleted again - strange stuff. Also 
> some file:warnings. Should I put these already in a bug report ?

Please do. 

> 
> It would be could if I could use winedbg, because I think it's more efficient.  
> Then I can really sneak near the places where it happens and then trace it
> down.
>
> Finally it can't be such a difficult thing with this file, I think, or ? It
> just wants to be rewrite several times from the start.

It should not be difficult. Unfortunately file operations in wine are
somewhat complicated the way they are handled by the separate process
wineserver.

> 
> I was wondering why the previous data was put to all to zero? Perhaps it 
> something like the lseek man says:  
> [...]
> The lseek function allows the file offset to be set beyond the end of the  
> existing  end-of-file  of  the  file (but this does not change the size of 
> the file).  If data is later written at this point, subsequent reads of the 
> data in the  gap  return  bytes  of  zeros (until data is actually written 
> into the gap).
> [...]

I can imagine it something like that. 

Rein.
-- 
Rein Klazes
rklazes at xs4all.nl