From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21818 invoked from network); 21 Sep 1999 16:45:11 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 21 Sep 1999 16:45:11 -0000 Received: (qmail 15531 invoked by alias); 21 Sep 1999 16:45:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7986 Received: (qmail 15523 invoked from network); 21 Sep 1999 16:45:03 -0000 From: "Bart Schaefer" Message-Id: <990921164414.ZM15530@candle.brasslantern.com> Date: Tue, 21 Sep 1999 16:44:14 +0000 In-Reply-To: <199909210905.LAA14475@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Crash while testing a completion: trap handlers and malloc?" (Sep 21, 11:05am) References: <199909210905.LAA14475@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Sven Wischnowsky , zsh-workers@sunsite.auc.dk Subject: Re: Crash while testing a completion: trap handlers and malloc? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 21, 11:05am, Sven Wischnowsky wrote: } Subject: Re: Crash while testing a completion: trap handlers and malloc? } } Bart Schaefer wrote: } } > got a core dump with the following huge stack trace. Note that the SIGALRM } > trap handler is being [...] called during zalloc(). } } I think the library should take care of this, but maybe if we move the } (|un)queue_signals() calls from our malloc down into zalloc() and friends? This was discussed a very long time ago (when the zsh memory routines were first introduced) and rejected by Zoltan on the grounds that it made it too slow to call malloc(). There are a couple mentions of this in the mailing list archives (e.g. zsh-workers/291 (yes, two hundred ninety one) and 1441) but the real discussion was on the old, pre-archives zsh-list. Given the recent changes that reduce the number of allocation calls that zsh makes in normal operation, and given that zhalloc() already contains queue_signals() calls, I wouldn't object to queuing signals around every possible call to malloc(). Note, however, that the calls in zhalloc() are needed independently, to protect zsh's own internal heap pointers from being garbled by a signal handler. So if we added queue_signals() calls lower down, we'd have to be sure that they "nest" properly with the ones in zhalloc(), so that an unqueue_signals() at a lower level doesn't prematurely allow signals into zhalloc(). (Remember the similar problems with child_block() that had to be worked around earlier in the 3.1.5-pws-* cycle?) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com