Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [BUG] SIGSEGV under certain circumstances
- X-seq: zsh-workers 40737
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Chi-Hsuan Yen <yan12125@xxxxxxxxx>
- Subject: Re: [BUG] SIGSEGV under certain circumstances
- Date: Sun, 5 Mar 2017 08:00:54 -0800
- Authentication-results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=brasslantern-com.20150623.gappssmtp.com
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- 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:cc :mime-version; bh=vhE2Dpxep4QK4v+/KnEqMf0e0xbr+K3Im1sVKFjv/Ok=; b=NyRn4m3/T5lmSSLnmKEZq3yKOFsHhug/JctUU0UWa+JV1Q02CgGGoVaIahARe/Yrad kEGBdcTaDXoICwQLAjW5SbpnNV2cxP8qo5oRx5M5vf3VC+F4Cp7tcmkRwNodotCPXAuz 5FjTFjc0wE000994fljiC+CAopq/+y7sjgtUlmnfyy6J+Wq4HXcQoSl3vQ1gztv7ZqQr c0F5T59sS59/0OaEPhQUAT2oIn9riXJOn7pWeRqtgUP5waXnEkD0TQ7Cf2qmk6Zww7l6 iBYI+N4obum2fp4tZTFFqJRpGn3mTpu0J6lexL2rDFmP5GT5IAo4Fy60YKwsI+LhgBDr ZJDQ==
- In-reply-to: <CAMNjDR0A-c=Q3AD1hCrbas3YRJ1VXp68KbSLcdMDFH7JQYNdng@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAMNjDR1CUaw2AXbEDLP94R=4VCNj1yc=d3OcVj=tO6FZXAEqPQ@mail.gmail.com> <170304151137.ZM30694@torch.brasslantern.com> <CAMNjDR0A-c=Q3AD1hCrbas3YRJ1VXp68KbSLcdMDFH7JQYNdng@mail.gmail.com>
On Mar 5, 9:09pm, Chi-Hsuan Yen wrote:
}
} Thanks for the tip. I re-compiled with commit
} 8522e996ecc88697344dcc4814367ec7e32e7deb and run zsh under valgrind.
Yes, this is much better, thank you.
The bad pointer dereference is in filename completion, not in the
history as I first suspected.
In computil.c:cfp_matcher_pats there is a loop that walks the string
from the command line, in this case the file name recalled from the
history, Comparing each character to the matcher pattern. If it gets
a match it adjusts some counters that are initialized from strlen() of
the candidate string, exiting the loop when the counters reach the
end of the string. It also adjusts pointers into string, and one of
those pointers is running past the end.
The pattern is m:{a-zA-Z}={A-Za-z} m:{a-zA-Z}={A-Za-z} but I don't
think that matters, it's the candidate string that's causing the
confusion.
You can see the string in Yen's third backtrace - I won't attempt to
paste the string here because my mail client will probably mangle it:
https://gist.github.com/yan12125/014c7a7510d1d9bd9ac8edf142a0c65d#file-gdb-backtrace-from-vgdb
It does not appear to be metafied but it contains some bytes that
were not in the original file name in his reproducing example.
So there seem to be two problems, one that the history is either not
saving or not reloading the Chinese characters correctly, and two
that the loop in cfp_matcher_pats is not counting correctly when it
examines that garbage string recalled from history.
I'm not in a good position multilingual-environment-wise to debug this
much further. Peter, you were the last person to touch the computil.c
code in this area, though it was a long time ago --
commit 7f470ebcb09972d46e947dddf0c16197dd3a312f
Author: Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxx>
Date: Sat Oct 18 19:16:24 2008 +0000
25912: fix another metafication bug in completion
and remove lies about matchers
-- do you have any thoughts on what's going on?
Messages sorted by:
Reverse Date,
Date,
Thread,
Author