First, my corrected understanding on stack allocation: initially
exec create stack mapping for process according with current system
or process (don't know) limits. Fork should duplicate that mapping
so your child has exactly the same vmspace. You should allocate
(or map) additional stack only if you need memory beyond those limits.
In other words if your system provides you with 8Mb of stack, you've
used 1M and need 2M more for child you should be in those limits.
Having said that, I'd first try fork1 with exact parent's stack.
And I beleive in this case you don't need to allocate it.


On Fri, Apr 26, 2002 at 10:29:00PM +0200, Emmanuel Dreyfus wrote:
> > What information SEGV gives you? Your clone started and segv-faulted
> > right away?
> 
> The child starts by an infinite loop, so that I can attach it with gdb,
> then jump outside the loop. During the different try I made to get
> things working, I have been able to attach the child. I had a SIGSEGV on
> a stack access.
> 
> With the version I posted, I get an immediate SIGSEGV, I don't even
> loop. I'm looking for a method to attach the child before it dies.

I suspect that your child process havn't reached user-space. So
I'd tried to catch it in kernel.

	Andrey