From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13217 invoked by alias); 3 Jul 2015 03:28:27 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35671 Received: (qmail 9333 invoked from network); 3 Jul 2015 03:28:25 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=2Z4Pexn2Jw5XDRSlxs83BQ+ParhGgU/iczSiPMbCiks=; b=Q8/1Jpp+RqHgRbUY+OG73YSuYQMdpmUFFXZ4V8h4b/VYX6ncSAUV647WC10xo5vg4A FjGNa2heC1FKr33AT0fFP9Lz2osI4r8Txno8Xpje9cDecXtY9yhOR5nLpDyWdVfxy8rz 5906XqeGmEs8f5INkhnw/5bcR6NuHOE3qSSQpADHrvaV0AsuYPzI1xdpbG3OzHHI8j/d LUNtRBuSVmP613hLA17GgcH+ucepGmkuVbPOjXgWk2i9OwELBXArGtCHBVoYXFZHOrv8 W7a8i1IVeMW8v8xO/Fci/d0YLHDZBAyxIoSXmJDcoGij6XmizIyhKDTAWRBSmYGrC6u8 pA+w== X-Gm-Message-State: ALoCoQnpfF4UyWICELOSpZ32mNyxfLPpakI3fjmmbJoj3LbPrgIeNSTfy9Fu27YGzsLZqqjXe6LO X-Received: by 10.60.123.51 with SMTP id lx19mr32831395oeb.46.1435894103418; Thu, 02 Jul 2015 20:28:23 -0700 (PDT) From: Bart Schaefer Message-Id: <150702202820.ZM11032@torch.brasslantern.com> Date: Thu, 2 Jul 2015 20:28:20 -0700 In-Reply-To: <5595AEF8.3000508@inlv.org> Comments: In reply to Martijn Dekker "Complicated segfault regression" (Jul 2, 11:36pm) References: <5595AEF8.3000508@inlv.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Complicated segfault regression MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 2, 11:36pm, Martijn Dekker wrote: } } The following code block makes zsh 5.0.8 and current git zsh segfault } reliably. It's now completely non-operational because I've tried to } reduce it to the minimum necessary to make zsh crash. So I tried executing this code from the shell prompt instead of as as script, with debugging output enabled. Following the "fi" I get: Src/text.c:970: unknown word code in gettext2() If I'm in GDB, I then immediately get a segfault on the following ":" command. I don't expect this stack trace is much help because the problem has already happened during parsing the preceding block, but: #0 0x008f228b in strlen () from /lib/tls/libc.so.6 #1 0x080c5df4 in taddstr (s=0xd5f29f7a
) at ../../zsh-5.0/Src/text.c:125 #2 0x080c5ff4 in taddassign (code=1600348549, state=0xbfe831d0, typeset=0) at ../../zsh-5.0/Src/text.c:181 #3 0x080c69a6 in gettext2 (state=0xbfe831d0) at ../../zsh-5.0/Src/text.c:484 #4 0x080c63d4 in getjobtext (prog=0xb7d945d8, c=0xb7d9460c) at ../../zsh-5.0/Src/text.c:314 If NOT in GDB, I don't get a crash, instead I get an infinite loop printing Src/text.c:49: attempting to decrement tindent below zero I can remove the "if" test and have only the "for ... case" and still get this: Src/text.c:970: unknown word code in gettext2() And if I add the opening parens to the case patterns, I get an infinite loop in gettext2() [never breaks out of the while(1) loop at line 396]. (s = tstack) is always true at 398; s->pop is always false at 400; wc_code(code) is always WC_END passing through line 967 which sets stack = 1 and we repeat at line 397 forever. So this has to have something to do with the updated parsing of (x|y) expressions in cond statements.