[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Static Space filling up



    Date: Sun, 24 Jan 88 16:48:00 PST
    From: luria@renoir.Berkeley.EDU (Marc Luria)

    I don't start any processes at all.  I do keep around a couple Lisp
    Window's and a couple Emacs windows.  During the last month, I've
    started a couple extra by accident by typing select-ctrl.  Don't
    processes use resources anyway?  That is, when I kill them, they
    should go away, right?

Processes don't use resources.  Many clients of processes keep resources
of processes.

    Date: Mon, 25 Jan 88 06:28 CST
    From: David D. Loeffler <Loeffler@MCC.COM>

    We had a problem here where the  stack space was filling up but  it when
    from about 14M  to 40M  (this could  happen in  15 minutes). The problem
    ended up being caused by two problems (both were consumers of the  stack
    area).  One was a site defined broadcaster server being envoked  several
    times a several times a second.  It in turn recreated several  processes
    via process-run-function (part of the  system code for default  handling
    of   broadcast   servers).       You   can   look   at   the    variable
    SI:PROCESS-RUN-FUNCTION-SPARE-PROCESSES and see if you have more than  3
    to 5 processes.  When one of these processes gets created initially  you
    lose  about  32K  to  64K  of  static  space.    We  fixed  the  problem
    temporarily by changing  our broadcaster  server function  definition so
    only one process was created and it loaded a queue that another  process
    handled.

This is a plausible situation and a reasonable way of fixing the
problem.

    Another problem we found was a routine that would automatically grow
    the stack if it overflowed.  A function was walking over a data
    structure recursively and it would sometimes bomb out because of a
    lack of stack space.  To keep this from happening an error handler
    was created that would grow the stack and then let the function
    continue to run.  This was okay until our data structures grew.  The
    problem was fixed by creating a more iterative function.

That is why  the default  on stack  overflow is  to cause  an error.  We
certainly don't  recommend  automatic  stack-growing.   If  you  have  a
program which uses more stack space than the default for a process, then
you should  create  the  process  with  sufficient  stack space for that
process.  At least that way you can still catch infinite recursion  with
the stack overflow error.

Gee, should I fill or adjust this paragraph?  Hmm...