From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21314 invoked by alias); 5 Mar 2017 21:45:21 -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: 40743 Received: (qmail 14867 invoked from network); 5 Mar 2017 21:45:21 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(205.235.26.22):SA:0(0.0/5.0):. Processed in 1.303719 secs); 05 Mar 2017 21:45:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=L5oX=2O=brasslantern.com=schaefer@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at bounces.park01.gkg.net does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=brasslantern-com.20150623.gappssmtp.com X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=GaVHELAIkN3GOddHMaSy7DqQyuDPkQNN0blG/GtkIGY=; b=rvfaF+4FAJy/fj/nLnB+yYF8f4qC/I8xNbdN0Nwcbw4P2AYvUqVo4nuO89mzGjGDTT DtAtUg2ppIikPbW2KIwbMWtfbJjU+8XrqjqoXzxzuple1DZCFjhpSNsXJngckEnvvf7X 9I5YlmL1nQK2h5XZDo8jBOGTYTJPhd61bDUWZ8T01x1/wcijr6Zuj6f5cJCfxC/mTP7u 6XDz4zUeTw1YIQJn+DevNJJAeeAVYLTsCBHQv3pSNdJUf48Hof9fIMCJJl+yxVJmMiJf 9DjFCY0CkQsKUwkMv3mVPl1+bMv6WeEF9a4XPedGiKRh0f/G5buIF0ietoKjlktWW2i4 oOHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=GaVHELAIkN3GOddHMaSy7DqQyuDPkQNN0blG/GtkIGY=; b=TUr98sMhTk35HOm+1sX8+28mciyR7sKcl0sxnxwFxlTlolZcjUC6WfQ8irS4ohaaRn hQrBLiNkRYiEW0BNj5nqdF0sfbOi6Oizb1OiNZsc5Yt1G9dVwN/s/RIgYBUDArTS9shR 7A6TkGUek40iKbfde7gkpgeeQFPXQ4c710vN4617KHEdPE6sJOwP6nPCk90hzlfy6ETL cVz1D+ASuQrgXfU/1K63XNNvAmxOlVPTe9bh0TMz55jgkmg8uExbi5OCLXAlCiTk6VUk lxTDabFbtWEPAccu1WKj775+BpHbEwdOZC3digNJ3GuS/eQZhfgs5pD5FjNIhc9Zap1V Ai1w== X-Gm-Message-State: AMke39nxyVtjFJRE4/wgodUY0TQh+jyiUY7UpSO/X3U48QLHLe6zQ1Te16xKnNC77VlHQw== X-Received: by 10.31.5.65 with SMTP id 62mr5159640vkf.167.1488750290171; Sun, 05 Mar 2017 13:44:50 -0800 (PST) From: Bart Schaefer Message-Id: <170305134513.ZM26364@torch.brasslantern.com> Date: Sun, 5 Mar 2017 13:45:13 -0800 In-Reply-To: <5096E600-D76C-4F71-BE93-C46F256BA7D7@ntlworld.com> Comments: In reply to Peter Stephenson "Re: [BUG] SIGSEGV under certain circumstances" (Mar 5, 6:52pm) References: <170304151137.ZM30694@torch.brasslantern.com> <170305080054.ZM24832@torch.brasslantern.com> <20170305161720.6f3773d6@ntlworld.com> <170305104239.ZM25231@torch.brasslantern.com> <5096E600-D76C-4F71-BE93-C46F256BA7D7@ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: [BUG] SIGSEGV under certain circumstances MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 5, 6:52pm, Peter Stephenson wrote: } } It needs at least to be able to do trivial matching, } character for character, or it becomes unusable. Point taken, though arguably it's *already* unusable if it crashes. Let's go back to the history angle ... from Yen's original message: } Chinese characters map to: } } e7aa81 e784b6 e5a5bd e683b3 e4bda0 } } in utf-8 (15 bytes, 3 bytes for each character). However, in } ~/.zsh_history, the saved content is: (I reformatted it for easier } comparision with the correct version) } } e7aa81 e783a4b6 e5a5bd e683a3b3 e4bd8380 Adding brackets to show metafied bytes: e7aa81 e7[83a4]b6 e5a5bd e6[83a3]b3 e4bd[8380] That is the same string that is passed to cfp_matcher_pats() according to the backtrace. So history is reading/writing correctly, it appears. However, note that it's not the first byte of the three in any of these examples that is metafied, and if we look at compmatch.c:pattern_match() we find this: /* * Now the line character. */ #ifdef MULTIBYTE_SUPPORT len = mb_metacharlenconv_r(s, &c, &lstate); #else /* We have the character itself. */ if (*s == Meta) { c = STOUC(s[1]) ^ 32; len = 2; } else { c = STOUC(*s); len = 1; } #endif This will fail in this case, I would think? We have to unmetafy first, possibly several bytes ahead, and THEN attempt multibyte conversion; not do either one or the other? So we're likely to get a false hit on pattern_match(), and in fact the bad dereference is of *mp in the branch where pattern_match() succeeds. [Somebody will have to explain to me why (mp += cl) makes sense, as that seems to be using a byte count to increment a (Cmatcher*), but it's done in several places.] Am I going astray here?