From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id CAA14981 for ; Sun, 7 Jul 1996 02:31:46 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id MAA15111; Sat, 6 Jul 1996 12:23:59 -0400 (EDT) Resent-Date: Sat, 6 Jul 1996 12:23:59 -0400 (EDT) From: "Bart Schaefer" Message-Id: <960706092417.ZM16934@candle.brasslantern.com> Date: Sat, 6 Jul 1996 09:24:16 -0700 In-Reply-To: Andreas Koenig "zsh-3.0-pre2 cores on irix 5.3 (?)" (Jul 6, 1:52pm) References: <199607061152.NAA20190@anna.in-berlin.de> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.702 02jul96) To: andreas.koenig@franz.ww.tu-berlin.de, zsh-workers@math.gatech.edu Subject: Re: zsh-3.0-pre2 cores on irix 5.3 (?) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"WW2os3.0.1i3.UCftn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1536 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jul 6, 1:52pm, Andreas Koenig wrote: } Subject: zsh-3.0-pre2 cores on irix 5.3 (?) } } As I had to rebuild my whole irix 5.3 from both CDROM and backup } tapes, this may be a due to a misconfiguration of my } machine. Nonetheless, recompiling beta19 works, pre2 results in a } core. } } exec.c: In function `execcmd': } exec.c:1318: warning: format argument is not a pointer (arg 3) That (and the core dump) are almost certainly from the DPUTS() typo that someone (Wayne?) already reported: --- zsh-3.0-pre2/Src/zsh.h Fri Jul 5 10:57:49 1996 +++ zsh-3.0-pre2-fix/Src/zsh.h Fri Jul 5 11:25:44 1996 @@ -1307,7 +1307,7 @@ #ifdef DEBUG # define DPUTS(X,Y) if (!(X)) {;} else \ - fprintf(stderr, "%s\n", X), fflush(stderr) + fprintf(stderr, "%s\n", Y), fflush(stderr) # define MUSTUSEHEAP(X) if (useheap) {;} else \ fprintf(stderr, "BUG: permanent allocation in %s\n", X), \ fflush(stderr) } #3 0x45db7c in loop (toplevel=0) at init.c:131 That line is this call: DPUTS(alloc_stackp, "BUG: alloc_stackp != 0 in loop()"); So apparently our allocation problems aren't all over with, yet. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"