Sprocs stack allocation problem

Sprocs stack allocation problem

Post by gndm_200 » Thu, 18 Sep 2003 00:29:02


Hi

I'm trying to create a process with a custom stack allocation using
code similiar to the following:

char* addr;

// code to compute stack address.
addr = computeAddr();

int pid = ::sprocsp(callBackFcn, FLAGS, (void *)this, addr, size);
assert (pid != -1);

int retPid = ::waitpid(pid, 0 , 0);
assert (retPid == pid);


This code compiles and runs, however the code inside callBackFcn never
gets executed. If I set addr = 0 before calling sprocsp the code in
callBackFcn gets executed as expected.

So, this leads me to believe something is wrong with the way I'm
computing the stack addr. However, using the same computeAddr() method
works fine for generating addresses used for stack allocation with
pthreads. There are no pthread calls inside the computeAddr() method,
just some memalign and mprotect calls.

So I'm pretty confused. Is it possible that the addr variable is
causing sprocsp to fail? (if so, wouldn't it return -1)?
What else could cause the callBackFcn not to execute?
 
 
 

Sprocs stack allocation problem

Post by dave » Thu, 18 Sep 2003 02:57:25

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



and

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.


Regards,
David B. Anderson XXXX@XXXXX.COM http://www.yqcomputer.com/

 
 
 

Sprocs stack allocation problem

Post by gndm_200 » Sun, 21 Sep 2003 02:45:11

es, it turns out I had the stack address pointing to the bottom of
the stack, instead of the top. (I had thought both pthreads and sprocs
expected the bottom of the stack as the parameter)

Thanks again for the help!
Stephen

XXXX@XXXXX.COM (David Anderson) wrote in message news:<bk7iu5$8j7sb$ XXXX@XXXXX.COM >...