Cygheap page boundary allocation bug.
Tue Dec 11 12:18:00 GMT 2007
My bug turned out to be a problem in the cygheap _csbrk routine. If an
allocation takes you exactly to the end of a granularity page, _csbrk calls
VirtualAlloc with a dwSize of zero bytes - the adjusted amount by which the heap
needs to be extended into the next page. VirtualAlloc doesn't like this and
returns win32 error 87 (ERROR_INVALID_PARAMETER), which fakes out _csbrk into
thinking there's no memory available.
(This was happening to me in the fork()'d child of g++.exe just as it was
passing through spawn_guts on its way to exec()'ing cc1plus.exe, resulting in
cc1plus.exe having an invalid environment when it got going. Amazingly enough,
it managed to stagger on through compilation and complete execution, and the
only symptom that something was wrong was that it gave an error when it couldn't
find a header file that I knew for sure was on the -I search path... because
GCC_CYGWIN_MINGW=1 had gone missing from the environment).
The fix is dead simple, just don't call VirtualAlloc: we get cygheap_max
pointing exactly to the first byte of the next unallocated granularity page, and
next time round - this is critically dependent on the current behaviour of the
nextpage() macro, which doesn't round a pointer to the very first byte of a page
to the next one, maybe that needs a comment to prevent someone thinking it's a
bug in the future - the page will be allocated.
Bug is present on, and patch applies cleanly to, both branch and trunk.
2007-12-11 Dave Korn <firstname.lastname@example.org>
* cygheap.cc (_csbrk): Don't request zero bytes from VirtualAlloc,
as windows treats that as an invalid parameter and returns an error.
Can't think of a witty .sigline today....
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 732 bytes
Desc: not available
More information about the Cygwin-patches