In article < XXXX@XXXXX.COM >,
It would be much more meaningful if you provided a *complete*
small example (compilable, runnable), not a sketch.
That said, note that the man page says:
The three calls differ in just two ways - how the stack for the new
process is initialized and in the interpretation of the inh argument. If
the argument sp is set to NULL then the system will create a stack region
for the child. This stack region will not overlap with any other area of
the share group's address space. These stack regions grow downward, and
are automatically grown if the process accesses new areas of the stack.
The len argument specifies how much margin (in bytes) the system should
attempt to leave for the child's stack. This margin is used when the
system attempts to place additional stacks or other virtual spaces (e.g.
from mmap). The system will attempt to leave enough room such that the
stack could grow to len bytes if it needs to. This margin in no way sets
a limit on stack growth nor guarantees a particular stack size. The
process can continue to grow its stack up to the maximum permissible size
(specified via the resource limit RLIMIT_STACK) as long as it doesn't run
If sp is set to a valid virtual address in the share group then the stack
of the new process is set to this value. With this option, the entire
responsibility of stack management is the calling process's. The system
will no longer attempt to automatically grow the process's stack region.
sp should point to the top (highest address) of the new stack. It will
automatically be rounded down to provide the appropriate alignment. No
validity checks are made on sp.
which suggests your provision for stack space is incorrect.
Also, note that the stack you provide should be aligned.
It would be best to ensure alignment to 16 byte boundary,
though 8 may work.
David B. Anderson XXXX@XXXXX.COM http://www.yqcomputer.com/