> -----Original Message-----
> From: cygwin-owner On Behalf Of Richard Troy
> Sent: 07 October 2004 15:57
[ We're getting a bit OT here, since this is generic programming stuff
rather than cygspecific, so if you want to discuss the generalities here any
further we should TITTTL. ]
> P.S. Igor,
I'm not Igor, but I'll do, since I was in the earlier thread!
> regarding execv(), I had indeed 'malloc'ed just
> enough memory
> for nargv and the extra null was in fact in non-malloced
> memory! Arg! What
> surprised me was that the write to that memory space was
> permitted and it
> failed sometime later when that memory location was needed/used for
> something else! (wtf? -frown- )
That's because the way that malloc implementations generally work is that
the crt startup code supplies a big block of memory ('heap'), and malloc
then allocates chunks from within that block for the application to use;
malloc only has to go back to the OS for more memory space every once in a
while, when the current heap runs out, rather than on every single
malloc/free operation. This makes for a good deal more efficiency, but has
the side effect that the memory chunks malloc gives you are in the middle of
the heap, with other valid malloc'd memory chunks on either side, rather
than in an isolated part of the process memory map with guard pages on each
side.
Overwriting the end of a buffer is a very heisenbug situation, since what
gets placed after any given buffer is highly variable, depending as it does
on some/all/many of the following factors, including: underlying OS/cpu
architecture, size of process environment, version of compiler and settings
of flags used to build application, versions of system libraries....... you
get the picture.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
