PATCH: set_thread_buffer fixed

Gerard Patel gerard.patel at
Tue Jun 5 11:14:52 CDT 2001

At 10:43 AM 05/06/2001 +0200, you wrote:
>> This calls fails because glibc detects that the value at (esp+28)
>> is different of 0 - the real system call is never done, with your
>> test app and Wine.
>Well, note that the second version is only pushing a 32bit offset, so
>mmap64 accesses random stack space!

Yes :-/

>Yes, check the sys/mman.h header, it should have __off64_t as argument
>to the mmap ... asm("mmap64") not __off_t.

Yes, it is __off_t and that is the problem; but how this header has come to
be in this
state is part of what I don't understand. It's marked as part of the glibc,
but there
is nothing like it in the glibc source that I used to compile. The mman.h in
my glibc
source is much shorter and the declaration of mmap64 seems correct.
I guess that the file in my /usr/include/sys/mman.h is a generated file.
I don't even want to count the number of 'mman.h' files on my system :-/

>So I think I can use this test program as check for mmap64 brokeness...

Btw, the reference on large files

says that locking will never be supported on 64 bits files with glibc 2.1.3 so
I don't see why it's necessary to support this case.


More information about the wine-devel mailing list