From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 929 invoked from network); 26 Sep 1999 14:38:06 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Sep 1999 14:38:06 -0000 Received: (qmail 2373 invoked by alias); 26 Sep 1999 14:37:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8049 Received: (qmail 2356 invoked from network); 26 Sep 1999 14:37:43 -0000 Message-Id: <9909261402.AA16846@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: BUG: permanent allocation in mathevall In-Reply-To: ""Bart Schaefer""'s message of "Sat, 25 Sep 1999 03:49:02 DFT." <990925034902.ZM29518@candle.brasslantern.com> Date: Sun, 26 Sep 1999 16:02:13 +0200 From: Peter Stephenson "Bart Schaefer" wrote: > I'm getting the "BUG: permanent allocation in mathevall" message every time > my TRAPALRM function fires. > > TRAPALRM () { > TMOUT=60 > title > } > > It's happening below getiparam("TMOUT"): > > Unfortunately, I'm not sure what to do about it. I believe signal handlers > deliberately avoid using the heap because of issues about when it should be > popped, but I don't recall for certain. It doesn't seem to be happening with TRAPUSR1, though: compare TRAPUSR1() { integer i; i=4; print i is $i; } kill -USR1 $$ with the same function as TRAPALRM with a non-zero timeout. Slightly odd. The easiest thing to do is to make user mathparse() gets called from mathevall() with heap allocation. It would be easy to write a heap-only version of dupstring(), in fact I would feel a lot happier if there was such a version, since dupstring() is almost always called with no intention of every freeing the space. However, the heap-alloced linked list for the function call rather sets the cat among the pigeons. We could zalloc() and free that, of course. With both these changes math evaluation would be independent of allocation strategy, apart from possible problems with calls into the parameter code, so maybe that's the right thing to do and this is just too lazy. There's an ancient issue with traps which has been in the back of mind for years: it would be much safer not to run them asynchronously at arbitrary points, but to set a flag and call the trap at one of several strategic points, e.g. after a foreground command has run or when an editor read is interrupted. This would mean traps not being run during a foreground programme, I don't know how many people that would inconvenience. We had some of this discussion a long time ago. --- Src/math.c.bak Thu Sep 23 15:42:20 1999 +++ Src/math.c Sun Sep 26 15:54:54 1999 @@ -852,7 +852,6 @@ struct mathvalue *xstack = 0, nstack[STACKSZ]; mnumber ret; - MUSTUSEHEAP("mathevall"); if (mlevel++) { xlastbase = lastbase; xnoeval = noeval; @@ -875,7 +874,9 @@ ptr = s; sp = -1; unary = 1; - mathparse(prek); + HEAPALLOC { + mathparse(prek); + } LASTALLOC; *ep = ptr; DPUTS(!errflag && sp, "BUG: math: wallabies roaming too freely in outback"); -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy