Mail Archives: cygwin/1997/11/15/13:19:42
In article <199711151549 DOT PAA30546 AT out1 DOT ibm DOT net>, <vischne AT ibm DOT net> wrote:
>I've been working on a partial cygwin32 version of Linux svgalib, with
>implemented SVGALib calls taken from the loader error messages you get
>when you compile zgv under cygwin32. I noticed that, when I try to use
>either HeapAlloc or GlobalAlloc to allocate a palette vector in libvga.a,
>the svga test program always crashes with the `WaitForMultipleObjects'
>message that goes with ntxlib under cygwin.
Yup. That's what the heap split error means.
If you allocate memory using something other than the mechanisms known
to cygwin's UNIX emulation (malloc, sbrk), then you'll put a stone wall
in the middle of cygwin's idea of heap. When cygwin extends its heap,
it will run into the stone wall, jump over it and continue.
You won't be able to fork after that point because cygwin won't know
what to do with the strange memory that is sitting in the middle of its
heap. That memory could be shared memory which would not be appropriate
to copy into the child's address space.
It is possible for cygwin to have its own versions of the *Heap*, *Alloc,
and shared memory routines which keep track of what is going on. Maybe
someday it will, and the heap split error will be a thing of the past.
Until then, you are mixing metaphors if you are using fork() with
Windows memory allocation calls.
--
http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal
VMS=>UNIX Solutions Boston Business Computing the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -