Sprocs stack allocation problem - SGI

This is a discussion on Sprocs stack allocation problem - SGI ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Sprocs stack allocation problem

  1. Sprocs stack allocation problem

    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?

  2. Re: Sprocs stack allocation problem

    In article ,
    Steven Wong wrote:
    >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?


    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 davea@sgi.com http://reality.sgiweb.org/davea

  3. Re: Sprocs stack allocation problem

    Yes, 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

    davea@quasar.engr.sgi.com (David Anderson) wrote in message news:...
    > In article ,
    > Steven Wong wrote:
    > >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?

    >
    > 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 davea@sgi.com http://reality.sgiweb.org/davea


+ Reply to Thread