Re: [Groff] Re: grops and grohtml problems on vista (walter harms)

[Ralph Corderoy]

Hi Boudewijn,

> I just tried StraceNT, here is part of the output generated when grops
> encounters 'x init'
> 
> [T5140] CreateFileA(34f818, c0000000, 3, 22fcd0, ...) = 104

Based on WINE, CreateFileA is almost the same as CreateFileW which is

    HANDLE WINAPI CreateFileW(LPCWSTR filename, DWORD access, DWORD sharing,
        LPSECURITY_ATTRIBUTES sa, DWORD creation,
        DWORD attributes, HANDLE template)

So we have access = 0xc0000000 and sharing = 3.  So access is READ |
WRITE:

    #define GENERIC_READ               0x80000000
    #define GENERIC_WRITE              0x40000000

and sharing is READ | WRITE:

    #define FILE_SHARE_READ                 0x00000001L
    #define FILE_SHARE_WRITE                0x00000002L
    #define FILE_SHARE_DELETE               0x00000004L

> I don't think the c0000000 is correct, in every other call to
> CreateFileA the second parameter is 80000000.

That sounds fine;  most of the other files are only being opened for
reading, GENERIC_READ.  The trace continues

> [T5140] GetFileType(104, 0, 0, 1065, ...) = 1
> [T5140] SetFilePointer(104, ffffffff, 0, 2, ...) = ffffffff
> [T5140] GetLastError(ffffffff, 22fd2c, 22fcf8, 77122b19, ...) = 83

0x104 is what CreateFileA returned.  SetFilePointer is

    http://source.winehq.org/source/dlls/kernel32/file.c#L936

and the 2 being passed is FILE_END with 0xffffffff = -1 the `distance'.
It returns INVALID_SET_FILE_POINTER = ~0 and GetLastError is returning
0x83 = ERROR_NEGATIVE_SEEK.

That then ripples through the next set of trace.

> [T5140] GetLastError(ffffffff, 3, 770ee2d4, 770f4fe0, ...) = 83
> [T5140] FlsGetValue(3, ffffffff, 3, 770ee2d4, ...) = 3407d8
> [T5140] SetLastError(83, ffffffff, 3, 770ee2d4, ...) = 0
> [T5140] GetLastError(ffffffff, 16, 770ea9c5, 770f4ff3, ...) = 83
> [T5140] FlsGetValue(3, ffffffff, 16, 770ea9c5, ...) = 3407d8
> [T5140] SetLastError(83, ffffffff, 16, 770ea9c5, ...) = 0
> [T5140] GetLastError(ffffffff, 22fd2c, 770ee2d4, 77122b28, ...) = 83
> [T5140] FlsGetValue(3, ffffffff, 22fd2c, 770ee2d4, ...) = 3407d8
> [T5140] SetLastError(83, ffffffff, 22fd2c, 770ee2d4, ...) = 0
> [T5140] LeaveCriticalSection(340a80, 22fd48, 7713db33, 3, ...) = 0
> [T5140] GetLastError(3, 34f818, 770ea9c5, 420229, ...) = 83
> [T5140] FlsGetValue(3, 3, 34f818, 770ea9c5, ...) = 3407d8
> [T5140] SetLastError(83, 3, 34f818, 770ea9c5, ...) = 0
> [T5140] GetLastError(0, 1, 770ea9c5, 77127c1a, ...) = 83
> [T5140] FlsGetValue(3, 0, 1, 770ea9c5, ...) = 3407d8
> [T5140] SetLastError(83, 0, 1, 770ea9c5, ...) = 0
> [T5140] OutputDebugStringA(77144cc0, 10001, 770ee31e, 22fadc, ...)
> Invalid parameter passed to C runtime function.
> = 22f168

Dont' know if that helps any.  I'd back the hunch of others in that the
mode of the file that's opened by the Windows kernel doesn't match the
later request to the C library with fdopen().  This `negative seek'
could just be a red-herring.  What happens for the `init x' on the case
where there's no problems;  the dvi one?

Cheers,


Ralph.