Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: segfault with certain filenames
- X-seq: zsh-workers 21850
- From: Clint Adams <clint@xxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: segfault with certain filenames
- Date: Thu, 6 Oct 2005 23:12:07 -0400
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <1051007023529.ZM3416@xxxxxxxxxxxxxxxxxxxxxxx>
- Mail-followup-to: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20051006232712.GA1886@xxxxxxxxxxx> <20051007003546.GA4637@xxxxxxxxxxx> <1051007023529.ZM3416@xxxxxxxxxxxxxxxxxxxxxxx>
> That's OK; it's useful to know that the bug happens not just with
> filenames exactly the width of the screen, but with sets of narrower
> filenames such that the end of the rightmost column is at the edge
> of the screen.
> If I'm interpreting your examples correctly, that is?
I was suspecting spaces as part of the problem.
In the 84-column xterm,
% touch "aaaaaaaaa bbbbbbbbb ccccccccc ddddddddd eeeeeeeee fffffffff ggggggggg hhhh".{10..50}
will also cause the problem.
So those are 77-char filenames, with 7 spaces escaped by backslashes,
causing the last digit of the filename to be at the edge of the screen.
In this case, the completion display is the ugliest i've seen yet:
% ls <one tab>
Completing files
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.10
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.11
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.12
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.13
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.14
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.15
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.16
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.17
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.18
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.19
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.20
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.21
aaaaaaaaa\ bbbbbbbbb\ ccccccccc\ ddddddddd\ eeeeeeeee\ fffffffff\ ggggggggg\ hhhh.22
At Top: Hit TAB for more, or the character to insert
(the xterm is 27 lines long, and this does not fill it)
Then after the second tab, those lines move to the top of the terminal,
and are followed by seven lines that end in ".2 ", six lines that end in
".3 ", and then ".36", and finally
"At 127%: Hit TAB for more, or the character to insert"
Note the impressive percentage.
After the third tab, there are six ".2 ", six ".3 ", one ".36", a blank
line (which the terminal thinks is a continuation of the .36), three
more ".3 ", ten ".4 ", and
"At 188%: Hit TAB for more, or the character to insert"
After the fourth tab, it just adds ".5 ", and the subdir "test" which I
forgot to remove. After this, it starts scrolling, and the redraw is
terrible. Somewhere around 23 tabs later, it segfaults.
#0 0xb7aecf71 in singledraw () at ../../../Src/Zle/complist.c:1641
g = 0x0
mc1 = 0
mc2 = 0
ml1 = -1
ml2 = -1
md1 = -1
md2 = -1
mcc1 = 0
mcc2 = 0
lc1 = 0
lc2 = 0
t1 = -1
t2 = -1
#1 0xb7aedaf0 in complistmatches (dummy=0xb7b74ab0, dat=0xbff01af0)
at ../../../Src/Zle/complist.c:1754
onlnct = 2
oamatches = 0x81ac000
#2 0x080962a7 in runhookdef (h=0xb7b74ab0, d=0xbff01af0)
at ../../Src/module.c:1889
No locals.
#3 0xb7b727ad in list_matches (dummy=0xb7baaf00, dummy2=0x0)
at ../../../Src/Zle/compresult.c:2214
dat = {matches = 0x81ac000, num = 42, nmesg = 87, cur = 0x0}
ret = -1209884684
#4 0x080962a7 in runhookdef (h=0xb7baaf00, d=0x0) at ../../Src/module.c:1889
No locals.
#5 0xb7b9290c in zrefresh () at ../../../Src/Zle/zle_refresh.c:767
inlist = 1
canscroll = 0
ln = 2
more_status = 0
nvcs = 16
nvln = 1
t0 = -1
tosln = 0
s = 0x8196af8
sen = 0x8196c08
t = 0x81a51f4
scs = 0x81a51f4
u = 0x81aa920
tmpline = 0x81a5098
qbuf = (ZLE_STRING_T *) 0x8109438
tmpcs = 87
tmpll = 87
tmpalloced = 0
remetafy = 0
#6 0xb7aef1fd in domenuselect (dummy=0xb7b74a74, dat=0xbff02130)
at ../../../Src/Zle/complist.c:2236
fdat = 0xbff02130
lastsearch = 0x0
p = (Cmatch **) 0x81af648
pg = (Cmgroup *) 0x81b2ec0
cmd = 0xb7ba9090
do_last_key = 0
u = 0x0
i = 1
acc = 0
wishcol = 0
setwish = 1
oe = 0
wasnext = 0
space = 26
lbeg = 0
step = 1
wrap = 135866768
pl = 1
broken = 0
first = 0
nolist = 0
mode = 0
modecs = 87
modell = 87
modelen = 84
wasmeta = 1
s = 0x0
status = "\000�\237�������8 ���`J���037�000\000\000\000C䶷\202]��\b\000\000\000��6��<\003�6��#x�\037�i�000\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000���\000\000\000\000\004 �005\003\000\000\000\000\000\000\000\000\000\000�237���\220)\031\b"
modeline = 0xb7bd25c0 "ls aaaaaaaaa\\ bbbbbbbbb\\ ccccccccc\\ ddddddddd\\ eeeeeeeee\\ fffffffff\\ ggggggggg\\ hhhh.10"
#7 0x08096242 in runhookdef (h=0xb7b74a74, d=0xbff02130)
at ../../Src/module.c:1883
p = 0x8193118
r = 135304368
#8 0xb7b5caa8 in after_complete (dummy=0xb7baaf3c, dat=0xbff021bc)
at ../../../Src/Zle/compcore.c:513
cdat = {matches = 0x81ac000, num = 42, nmesg = 0, cur = 0x0}
ret = -1210717646
#9 0x080962a7 in runhookdef (h=0xb7baaf3c, d=0xbff021bc)
at ../../Src/module.c:1889
No locals.
#10 0xb7b97c38 in docomplete (lst=0) at ../../../Src/Zle/zle_tricky.c:851
active = 1
s = 0x81948a8 "\210)\031\b8\216\031\b\020"
ol = 0x0
olst = 0
chl = 0
ne = 0
ocs = 3
ret = 1
dat = {0, 1}
#11 0xb7b96370 in completeword (args=0xb7bab17c)
at ../../../Src/Zle/zle_tricky.c:232
ret = 67
#12 0xb7b9624d in completecall (args=0xb7bab17c)
at ../../../Src/Zle/zle_tricky.c:208
[...all the way to #24 in main]
I've had other instances that I probably can't reproduce when it would
segfault on the first or second line of scrolling, and not in
singledraw().
Messages sorted by:
Reverse Date,
Date,
Thread,
Author