zsh-workers
 help / color / mirror / code / Atom feed
* Re: core dump with completion.
  1999-07-21 15:50 core dump with completion Tanaka Akira
@ 1999-07-21 15:49 ` Peter Stephenson
  1999-07-21 16:14 ` Bart Schaefer
  1 sibling, 0 replies; 11+ messages in thread
From: Peter Stephenson @ 1999-07-21 15:49 UTC (permalink / raw)
  To: zsh-workers

Tanaka Akira wrote:
> zsh dumps core with completion with following operation.
> $ bin/zsh -f
> is27e1u11% bindkey -e; autoload -U compinit; compinit
> is27e1u11% cvs add <TAB><C-c>
> is27e1u11% A=sh<TAB>zsh: segmentation fault (core dumped)  bin/zsh -f
> 
> The backtrace is follows.
> #0  0xff136bf8 in strlen ()
> #1  0x699a4 in dupstring (s=0x1 <Address 0x1 out of bounds>) at mem.c:494
> #2  0x97c04 in arrdup (s=0x14b094) at utils.c:2234
> #3  0xff1dbb78 in comp_wrapper (list=0x0, w=0x0, name=0x1204d0 "_first")
>     at compctl.c:2412

Something's happening in _first.  This is a no-op by default, so if you have
something different it might help to see it.  If not then... er.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


^ permalink raw reply	[flat|nested] 11+ messages in thread

* core dump with completion.
@ 1999-07-21 15:50 Tanaka Akira
  1999-07-21 15:49 ` Peter Stephenson
  1999-07-21 16:14 ` Bart Schaefer
  0 siblings, 2 replies; 11+ messages in thread
From: Tanaka Akira @ 1999-07-21 15:50 UTC (permalink / raw)
  To: zsh-workers

zsh dumps core with completion with following operation.

Script started, file is typescript
$ ls
7196              7217              7230              share
7202              7218              7231              typescript
7205              7219              7235              u2456
7209              7220              7241              zsh-3.1.6-test-2
7210              7223              bin
7213              7226              lib
7216              7229              man
$ bin/zsh -f
is27e1u11% bindkey -e; autoload -U compinit; compinit
is27e1u11% cvs add <TAB><C-c>
is27e1u11% A=sh<TAB>zsh: segmentation fault (core dumped)  bin/zsh -f
$ Script done, file is typescript

The backtrace is follows.

Z:akr@is27e1u11% gdb bin/zsh core
GNU gdb 19981224
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...
Core was generated by `bin/zsh -f'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libcurses.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.
Reading symbols from /home/fs114/akr/zsh/y/lib/zsh/3.1.6-test-2/comp1.so...
done.
Reading symbols from /home/fs114/akr/zsh/y/lib/zsh/3.1.6-test-2/zle.so...done.
Reading symbols from /home/fs114/akr/zsh/y/lib/zsh/3.1.6-test-2/compctl.so...
done.
#0  0xff136bf8 in strlen ()
(gdb) where
#0  0xff136bf8 in strlen ()
#1  0x699a4 in dupstring (s=0x1 <Address 0x1 out of bounds>) at mem.c:494
#2  0x97c04 in arrdup (s=0x14b094) at utils.c:2234
#3  0xff1dbb78 in comp_wrapper (list=0x0, w=0x0, name=0x1204d0 "_first")
    at compctl.c:2412
#4  0x37f78 in runshfunc (list=0x0, wrap=0xff1ed770, name=0x1204d0 "_first")
    at exec.c:3006
#5  0x37c70 in doshfunc (name=0x1204d0 "_first", list=0x0, doshargs=0x1197c0, 
    flags=2048, noreturnval=0) at exec.c:2957
#6  0x37654 in execshfunc (cmd=0x10a5f8, shf=0x120298, args=0x1197c0)
    at exec.c:2850
#7  0x343f4 in execcmd (cmd=0x10a5f8, input=0, output=0, how=2, last1=2)
    at exec.c:2013
#8  0x300e0 in execpline2 (pline=0x10a758, how=2, input=0, output=0, last1=0)
    at exec.c:1054
#9  0x2f240 in execpline (l=0x109b90, how=2, last1=0) at exec.c:869
#10 0x2eb68 in execlist (list=0x109360, dont_change_job=1, exiting=0)
    at exec.c:738
#11 0x639b8 in execif (cmd=0x106dd0, args=0x0, flags=0) at loop.c:404
#12 0x34164 in execcmd (cmd=0x106dd0, input=0, output=0, how=2, last1=2)
    at exec.c:1976
#13 0x300e0 in execpline2 (pline=0x10d1a0, how=2, input=0, output=0, last1=0)
    at exec.c:1054
#14 0x2f240 in execpline (l=0x109b30, how=2, last1=0) at exec.c:869
#15 0x2eb68 in execlist (list=0x108060, dont_change_job=1, exiting=0)
    at exec.c:738
#16 0x38048 in runshfunc (list=0x10b510, wrap=0x0, name=0x11fb70 "_complete")
    at exec.c:3019
#17 0xff1dbbf0 in comp_wrapper (list=0x10b510, w=0x0, 
    name=0x11fb70 "_complete") at compctl.c:2415
#18 0x37f78 in runshfunc (list=0x10b510, wrap=0xff1ed770, 
    name=0x11fb70 "_complete") at exec.c:3006
#19 0x37c70 in doshfunc (name=0x11fb70 "_complete", list=0x10b510, 
    doshargs=0x119570, flags=2048, noreturnval=0) at exec.c:2957
---Type <return> to continue, or q <return> to quit---
#20 0x37654 in execshfunc (cmd=0x106d58, shf=0x11fb28, args=0x119570)
    at exec.c:2850
#21 0x343f4 in execcmd (cmd=0x106d58, input=0, output=0, how=2, last1=2)
    at exec.c:2013
#22 0x300e0 in execpline2 (pline=0x10c8b0, how=2, input=0, output=0, last1=0)
    at exec.c:1054
#23 0x2f240 in execpline (l=0x1077e0, how=2, last1=0) at exec.c:869
#24 0x2eb68 in execlist (list=0x10c958, dont_change_job=1, exiting=0)
    at exec.c:738
#25 0x63838 in execif (cmd=0x106da8, args=0x0, flags=0) at loop.c:392
#26 0x34164 in execcmd (cmd=0x106da8, input=0, output=0, how=2, last1=2)
    at exec.c:1976
#27 0x300e0 in execpline2 (pline=0x1085a8, how=2, input=0, output=0, last1=0)
    at exec.c:1054
#28 0x2f240 in execpline (l=0x10bc58, how=2, last1=0) at exec.c:869
#29 0x2eb68 in execlist (list=0x108590, dont_change_job=1, exiting=0)
    at exec.c:738
#30 0x62410 in execfor (cmd=0x106d80, args=0x119530, flags=0) at loop.c:117
#31 0x34164 in execcmd (cmd=0x106d80, input=0, output=0, how=2, last1=2)
    at exec.c:1976
#32 0x300e0 in execpline2 (pline=0x108578, how=2, input=0, output=0, last1=0)
    at exec.c:1054
#33 0x2f240 in execpline (l=0x109750, how=2, last1=0) at exec.c:869
#34 0x2eb68 in execlist (list=0x10c7f0, dont_change_job=1, exiting=0)
    at exec.c:738
#35 0x38048 in runshfunc (list=0x1084e0, wrap=0x0, 
    name=0x116e30 "_main_complete") at exec.c:3019
#36 0xff1dbbf0 in comp_wrapper (list=0x1084e0, w=0x0, 
    name=0x116e30 "_main_complete") at compctl.c:2415
#37 0x37f78 in runshfunc (list=0x1084e0, wrap=0xff1ed770, 
    name=0x116e30 "_main_complete") at exec.c:3006
#38 0x37c70 in doshfunc (name=0x116e30 "_main_complete", list=0x1084e0, 
    doshargs=0x0, flags=0, noreturnval=0) at exec.c:2957
#39 0xff0c9554 in callcompfunc (s=0xce230 "sh", fn=0x116e30 "_main_complete")
---Type <return> to continue, or q <return> to quit---
    at zle_tricky.c:4775
#40 0xff0c9f28 in makecomplist (s=0xce230 "sh", incmd=0, lst=0)
    at zle_tricky.c:4932
#41 0xff0c7de0 in docompletion (s=0x10ccd0 "sh", lst=0, incmd=0)
    at zle_tricky.c:4449
#42 0xff0ba730 in docomplete (lst=0) at zle_tricky.c:1076
#43 0xff0b7be8 in expandorcomplete (args=0xff0f8070) at zle_tricky.c:491
#44 0xff0b7678 in completecall (args=0xff0f8070) at zle_tricky.c:390
#45 0xff0a8974 in execzlefunc (func=0xff0f5fcc, args=0xff0f8070)
    at zle_main.c:628
#46 0xff0a8468 in zleread (lp=0xc95e8 "%m%# ", rp=0x0, flags=3)
    at zle_main.c:547
#47 0x54c94 in inputline () at input.c:265
#48 0x54a60 in ingetc () at input.c:210
#49 0x4a980 in ihgetc () at hist.c:242
#50 0x5cb2c in gettok () at lex.c:545
#51 0x5be90 in yylex () at lex.c:308
#52 0x79d24 in parse_event () at parse.c:105
#53 0x514cc in loop (toplevel=1, justonce=0) at init.c:113
#54 0x1a8b8 in main (argc=2, argv=0xffbef6dc) at ./main.c:89
(gdb) 

typescript is follows.

begin 644 typescript
M4V-R:7!T('-T87)T960@;VX@5&AU($IU;" R,B P,#HT-#HR.2 Q.3DY"@T;
M6VT;6VT;6VT;6THD(!M;2VP(;',-#0HW,3DV(" @(" @(" @(" @(" W,C$W
M(" @(" @(" @(" @(" W,C,P(" @(" @(" @(" @("!S:&%R90T*-S(P,B @
M(" @(" @(" @(" @-S(Q." @(" @(" @(" @(" @-S(S,2 @(" @(" @(" @
M(" @='EP97-C<FEP= T*-S(P-2 @(" @(" @(" @(" @-S(Q.2 @(" @(" @
M(" @(" @-S(S-2 @(" @(" @(" @(" @=3(T-38-"C<R,#D@(" @(" @(" @
M(" @(#<R,C @(" @(" @(" @(" @(#<R-#$@(" @(" @(" @(" @('IS:"TS
M+C$N-BUT97-T+3(-"C<R,3 @(" @(" @(" @(" @(#<R,C,@(" @(" @(" @
M(" @(&)I;@T*-S(Q,R @(" @(" @(" @(" @-S(R-B @(" @(" @(" @(" @
M;&EB#0HW,C$V(" @(" @(" @(" @(" W,C(Y(" @(" @(" @(" @("!M86X-
M"@T;6VT;6VT;6VT;6THD(!M;2V((8FEN+WIS:" M9@T-"@T;6VT;6VT;6VT;
M6TII<S(W93%U,3$E(!M;2V((8FEN9&ME>2 M93L@875T;VQO860@+54@8V]M
M<&EN:70[(&-O;7!I;FET#0T*#1M;;1M;;1M;;1M;2FES,C=E,74Q,24@&UM+
M8PAC=G,@861D( <-#0HM:R @(" @(" @(" @(" @(" @-S(Q,R @(" @(" @
M(" @(" @(#<R,C8@(" @(" @(" @(" @("!L:6(O#0HM;2 @(" @(" @(" @
M(" @(" @-S(Q-B @(" @(" @(" @(" @(#<R,CD@(" @(" @(" @(" @("!M
M86XO#0HW,3DV(" @(" @(" @(" @(" @-S(Q-R @(" @(" @(" @(" @(#<R
M,S @(" @(" @(" @(" @("!S:&%R92\-"C<R,#(@(" @(" @(" @(" @(" W
M,C$X(" @(" @(" @(" @(" @-S(S,2 @(" @(" @(" @(" @('1Y<&5S8W)I
M<'0@#0HW,C U(" @(" @(" @(" @(" @-S(Q.2 @(" @(" @(" @(" @(#<R
M,S4@(" @(" @(" @(" @("!U,C0U-B -"C<R,#D@(" @(" @(" @(" @(" W
M,C(P(" @(" @(" @(" @(" @-S(T,2 @(" @(" @(" @(" @('IS:"TS+C$N
M-BUT97-T+3(O#0HW,C$P(" @(" @(" @(" @(" @-S(R,R @(" @(" @(" @
M(" @(&)I;B\@(" @(" @(" @(" @(" ;6S=!&UMM&UMM&UMM#1M;,3%#&ULX
M0PT-"AM;2@T;6VT;6VT;6VT;6TII<S(W93%U,3$E(!M;2T$(03US:'IS:#H@
M<V5G;65N=&%T:6]N(&9A=6QT("AC;W)E(&1U;7!E9"D@(&)I;B]Z<V@@+68-
M"@T;6VT;6VT;6VT;6THD(!M;2PT-"GIS:#H@9&\@>6]U('=I<V@@=&\@<V5E
M(&%L;" R.3$W('!O<W-I8FEL:71I97,_(&X-&UM*&UM!&UMM&UMM&UMM#1M;
K,D,*<V-R:7!T(&1O;F4@;VX@5&AU($IU;" R,B P,#HT-3HP-B Q.3DY"AM;
 
end
-- 
Tanaka Akira


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: core dump with completion.
  1999-07-21 15:50 core dump with completion Tanaka Akira
  1999-07-21 15:49 ` Peter Stephenson
@ 1999-07-21 16:14 ` Bart Schaefer
  1999-07-21 17:02   ` Tanaka Akira
  1 sibling, 1 reply; 11+ messages in thread
From: Bart Schaefer @ 1999-07-21 16:14 UTC (permalink / raw)
  To: zsh-workers

On Jul 22, 12:50am, Tanaka Akira wrote:
} Subject: core dump with completion.
}
} zsh dumps core with completion with following operation.
} 
} Script started, file is typescript
} $ ls
} 7196              7217              7230              share
} 7202              7218              7231              typescript
} 7205              7219              7235              u2456
} 7209              7220              7241              zsh-3.1.6-test-2
} 7210              7223              bin
} 7213              7226              lib
} 7216              7229              man
} $ bin/zsh -f
} is27e1u11% bindkey -e; autoload -U compinit; compinit
} is27e1u11% cvs add <TAB><C-c>
} is27e1u11% A=sh<TAB>zsh: segmentation fault (core dumped)  bin/zsh -f

I can't reproduce this; at least, not in a 3.1.5 static-build tree replacing
"bin/zsh -f" with "Src/zsh -f".  Maybe it's a dynamic linkage thing.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: core dump with completion.
  1999-07-21 16:14 ` Bart Schaefer
@ 1999-07-21 17:02   ` Tanaka Akira
  0 siblings, 0 replies; 11+ messages in thread
From: Tanaka Akira @ 1999-07-21 17:02 UTC (permalink / raw)
  To: zsh-workers

In article <990721161435.ZM6916@candle.brasslantern.com>,
  "Bart Schaefer" <schaefer@candle.brasslantern.com> writes:

> I can't reproduce this; at least, not in a 3.1.5 static-build tree replacing
> "bin/zsh -f" with "Src/zsh -f".  Maybe it's a dynamic linkage thing.

I retried zsh-3.1.6-test-2 with patches upto 7243 and --disable-dynamic.
But it is reproduced.

In article <9907211549.AA13416@ibmth.df.unipi.it>,
  Peter Stephenson <pws@ibmth.df.unipi.it> writes:

> Something's happening in _first.  This is a no-op by default, so if you have
> something different it might help to see it.  If not then... er.

_first is not modified. And share/zsh/functions/* are not modified at
all.

#0  0xff136bf8 in strlen ()
(gdb) up
#1  0x6df68 in dupstring (s=0x1 <Address 0x1 out of bounds>) at mem.c:494
494         t = (char *)ncalloc(strlen((char *)s) + 1);
(gdb) up
#2  0x98424 in arrdup (s=0x1a754c) at utils.c:2234
2234        while ((*x++ = dupstring(*s++)));
(gdb) up
#3  0xabf40 in comp_wrapper (list=0x0, w=0x0, name=0x17c770 "_first")
    at compctl.c:2412
2412                owords = arrdup(compwords);
(gdb) print compwords[0]
$1 = 0x162c80 "sh"
(gdb) print compwords[1]
$2 = 0x1a7c10 ""
(gdb) print compwords[2]
$3 = 0x1 <Address 0x1 out of bounds>
(gdb) print compwords[3]
$4 = 0x0
(gdb) 

Hm...
-- 
Tanaka Akira


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: core dump with completion
  2000-01-28 13:55 Sven Wischnowsky
@ 2000-01-28 16:26 ` Tanaka Akira
  0 siblings, 0 replies; 11+ messages in thread
From: Tanaka Akira @ 2000-01-28 16:26 UTC (permalink / raw)
  To: zsh-workers

In article <200001281355.OAA25741@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> The last hunk makes zsh use heap memory when listing the completions,
> Tanaka, could you please try it without that hunk? To see if the other
> stuff fixes the bug.

I confirmed that 9458 without the last hunk fixes the problem.  Thanks.
-- 
Tanaka Akira


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: core dump with completion
@ 2000-01-28 13:55 Sven Wischnowsky
  2000-01-28 16:26 ` Tanaka Akira
  0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 2000-01-28 13:55 UTC (permalink / raw)
  To: zsh-workers


Tanaka Akira wrote:

> In article <200001261009.LAA16179@beta.informatik.hu-berlin.de>,
>   Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
> > But I can't repeat the bug. Tanaka, can you try it using --enable-zsh-mem,
> > --enable-secure-free and --enable-mem-warining? That may (or may not)
> > give us more information where it is actually failing. Also: does it
> > use mmap for heaps on Solaris 7?
> 
> zsh built with 
>   ./configure --prefix=/space/akr/zsh/tmp --enable-zsh-debug --enable-zsh-mem-debug --enable-zsh-mem --enable-secure-free --enable-mem-warining
> doesn't dump core.  It seems to work well.
> 
> Since `egrep 'HAVE_SYS_MMAN_H|HAVE_MMAP|HAVE_MUNMAP' config.h' says
> follows, mmap is used, maybe.
> 
> #define HAVE_MMAP 1
> #define HAVE_MUNMAP 1
> #define HAVE_SYS_MMAN_H 1
> 
> Also note that I found zsh patched upto 9419 doesn't have the problem.
> So I suspect the problem is related to 9421.

That was a hint... I still couldn't reproduce it (of course, that
would have been too easy, sigh), but I found a place where freed
memory was accessed. So, if the allocator somehow re-uses the
memory...

The last hunk makes zsh use heap memory when listing the completions,
Tanaka, could you please try it without that hunk? To see if the other
stuff fixes the bug.

Bye
 Sven

diff -ru ../z.old/Src/Zle/complete.c Src/Zle/complete.c
--- ../z.old/Src/Zle/complete.c	Fri Jan 28 14:08:53 2000
+++ Src/Zle/complete.c	Fri Jan 28 14:45:44 2000
@@ -1026,7 +1026,7 @@
 
     comprpms[CPN_COMPSTATE] = cpm;
     tht = paramtab;
-    cpm->level = locallevel;
+    cpm->level = locallevel + 1;
     cpm->gets.hfn = get_compstate;
     cpm->sets.hfn = set_compstate;
     cpm->unsetfn = compunsetfn;
@@ -1146,8 +1146,24 @@
 	    }
 	}
     } else if (PM_TYPE(pm->flags) == PM_HASHED) {
+	Param *p;
+	int i;
+
 	deletehashtable(pm->u.hash);
 	pm->u.hash = NULL;
+
+	for (p = compkpms, i = CP_KEYPARAMS; i--; p++)
+	    *p = NULL;
+    }
+    if (!exp) {
+	Param *p;
+	int i;
+
+	for (p = comprpms, i = CP_REALPARAMS; i; p++, i--)
+	    if (*p == pm) {
+		*p = NULL;
+		break;
+	    }
     }
 }
 
@@ -1159,18 +1175,22 @@
 
     if (comprpms && (rset >= 0 || runset >= 0)) {
 	for (p = comprpms; rset || runset; rset >>= 1, runset >>= 1, p++) {
-	    if (rset & 1)
-		(*p)->flags &= ~PM_UNSET;
-	    if (runset & 1)
-		(*p)->flags |= PM_UNSET;
+	    if (*p) {
+		if (rset & 1)
+		    (*p)->flags &= ~PM_UNSET;
+		if (runset & 1)
+		    (*p)->flags |= PM_UNSET;
+	    }
 	}
     }
-    if (comprpms && (kset >= 0 || kunset >= 0)) {
+    if (compkpms && (kset >= 0 || kunset >= 0)) {
 	for (p = compkpms; kset || kunset; kset >>= 1, kunset >>= 1, p++) {
-	    if (kset & 1)
-		(*p)->flags &= ~PM_UNSET;
-	    if (kunset & 1)
-		(*p)->flags |= PM_UNSET;
+	    if (*p) {
+		if (kset & 1)
+		    (*p)->flags &= ~PM_UNSET;
+		if (kunset & 1)
+		    (*p)->flags |= PM_UNSET;
+	    }
 	}
     }
 }
diff -ru ../z.old/Src/Zle/compresult.c Src/Zle/compresult.c
--- ../z.old/Src/Zle/compresult.c	Fri Jan 28 14:08:54 2000
+++ Src/Zle/compresult.c	Fri Jan 28 14:50:19 2000
@@ -1828,19 +1828,24 @@
 list_matches(Hookdef dummy, void *dummy2)
 {
     struct chdata dat;
+    int ret;
 
+    HEAPALLOC {
 #ifdef DEBUG
-    /* Sanity check */
-    if (!validlist) {
-	showmsg("BUG: listmatches called with bogus list");
-	return 1;
-    }
+	/* Sanity check */
+	if (!validlist) {
+	    showmsg("BUG: listmatches called with bogus list");
+	    return 1;
+	}
 #endif
 
-    dat.matches = amatches;
-    dat.num = nmatches;
-    dat.cur = NULL;
-    return runhookdef(COMPLISTMATCHESHOOK, (void *) &dat);
+	dat.matches = amatches;
+	dat.num = nmatches;
+	dat.cur = NULL;
+	ret = runhookdef(COMPLISTMATCHESHOOK, (void *) &dat);
+    } LASTALLOC;
+
+    return ret;
 }
 
 /* Invalidate the completion list. */

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: core dump with completion
  2000-01-26 10:09 Sven Wischnowsky
@ 2000-01-26 11:54 ` Tanaka Akira
  0 siblings, 0 replies; 11+ messages in thread
From: Tanaka Akira @ 2000-01-26 11:54 UTC (permalink / raw)
  To: zsh-workers

In article <200001261009.LAA16179@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> But I can't repeat the bug. Tanaka, can you try it using --enable-zsh-mem,
> --enable-secure-free and --enable-mem-warining? That may (or may not)
> give us more information where it is actually failing. Also: does it
> use mmap for heaps on Solaris 7?

zsh built with 
  ./configure --prefix=/space/akr/zsh/tmp --enable-zsh-debug --enable-zsh-mem-debug --enable-zsh-mem --enable-secure-free --enable-mem-warining
doesn't dump core.  It seems to work well.

Since `egrep 'HAVE_SYS_MMAN_H|HAVE_MMAP|HAVE_MUNMAP' config.h' says
follows, mmap is used, maybe.

#define HAVE_MMAP 1
#define HAVE_MUNMAP 1
#define HAVE_SYS_MMAN_H 1

Also note that I found zsh patched upto 9419 doesn't have the problem.
So I suspect the problem is related to 9421.
-- 
Tanaka Akira


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: core dump with completion
@ 2000-01-26 10:09 Sven Wischnowsky
  2000-01-26 11:54 ` Tanaka Akira
  0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 2000-01-26 10:09 UTC (permalink / raw)
  To: zsh-workers


Tanaka Akira wrote:

> zsh patched upto 9421 dumps core on Solaris 7 as follows:
> 
> Z:akr@is27e1u11% cvs co -r zsh-workers_9421 -d zsh9421 zsh
> Z:akr@is27e1u11% cd zsh9421
> Z:akr@is27e1u11% Util/preconfig
> Z:akr@is27e1u11%  ./configure --prefix=/space/akr/zsh/tmp --enable-zsh-debug --enable-zsh-mem-debug && make && make install
> Z:akr@is27e1u11% Src/zsh -f
> is27e1u11% bindkey -e; autoload -U compinit; compinit -D
> is27e1u11% ls c<TAB>
> is27e1u11% ls config<TAB>
> zsh: segmentation fault (core dumped)  Src/zsh -f
> Z:akr@is27e1u11% 

Damn. I hate memory bugs.

> (gdb) where
> #0  0xff145c8c in realfree ()
> #1  0xff146460 in cleanfree ()
> #2  0xff145628 in _malloc_unlocked ()
> #3  0xff145544 in malloc ()
> #4  0x681d0 in zalloc (size=45) at mem.c:491

Urgh. It shouldn't be using zalloc'ed memory here. I can easily send a 
patch for this, but...

All this seems to show some other allocation bug (I guess some
function writes into memory it hasn't allocated) which might be hidden 
if I send the patch to make it use heap memory now, so...

But I can't repeat the bug. Tanaka, can you try it using --enable-zsh-mem,
--enable-secure-free and --enable-mem-warining? That may (or may not)
give us more information where it is actually failing. Also: does it
use mmap for heaps on Solaris 7?


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 11+ messages in thread

* core dump with completion
@ 2000-01-26  7:45 Tanaka Akira
  0 siblings, 0 replies; 11+ messages in thread
From: Tanaka Akira @ 2000-01-26  7:45 UTC (permalink / raw)
  To: zsh-workers

zsh patched upto 9421 dumps core on Solaris 7 as follows:

Z:akr@is27e1u11% cvs co -r zsh-workers_9421 -d zsh9421 zsh
Z:akr@is27e1u11% cd zsh9421
Z:akr@is27e1u11% Util/preconfig
Z:akr@is27e1u11%  ./configure --prefix=/space/akr/zsh/tmp --enable-zsh-debug --enable-zsh-mem-debug && make && make install
Z:akr@is27e1u11% Src/zsh -f
is27e1u11% bindkey -e; autoload -U compinit; compinit -D
is27e1u11% ls c<TAB>
is27e1u11% ls config<TAB>
zsh: segmentation fault (core dumped)  Src/zsh -f
Z:akr@is27e1u11% 

(gdb) where
#0  0xff145c8c in realfree ()
#1  0xff146460 in cleanfree ()
#2  0xff145628 in _malloc_unlocked ()
#3  0xff145544 in malloc ()
#4  0x681d0 in zalloc (size=45) at mem.c:491
#5  0x683d8 in dupstring (
    s=0x10eeb8 "no=0:fi=0:di=0:ln=0:pi=0:so=0:bd=0:cd=0:ex=0") at mem.c:555
#6  0xff023604 in getcols (c=0xff038304) at complist.c:360
#7  0xff025340 in complistmatches (dummy=0xff0967e4, dat=0xffbeefe0)
    at complist.c:767
#8  0x6d370 in runhookdef (h=0xff0967e4, d=0xffbeefe0) at module.c:1613
#9  0xff0849dc in list_matches (dummy=0xff0ee4c8, dummy2=0x0)
    at compresult.c:1842
#10 0x6d370 in runhookdef (h=0xff0ee4c8, d=0x0) at module.c:1613
#11 0xff0c0fb8 in zrefresh () at zle_refresh.c:602
#12 0xff0b6cc0 in zleread (lp=0xd5eb0 "%m%# ", rp=0x0, flags=3)
    at zle_main.c:589
#13 0x53ab4 in inputline () at input.c:265
#14 0x53880 in ingetc () at input.c:210
#15 0x490fc in ihgetc () at hist.c:242
#16 0x5ba70 in gettok () at lex.c:560
#17 0x5adcc in yylex () at lex.c:313
#18 0x7a0a0 in parse_event () at parse.c:292
#19 0x4fcf0 in loop (toplevel=1, justonce=0) at init.c:115
#20 0x1b2a8 in main (argc=2, argv=0xffbef6ac) at ./main.c:89
(gdb) 
-- 
Tanaka Akira


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: core dump with completion.
  1999-07-22  7:18 Sven Wischnowsky
@ 1999-07-22  7:32 ` Tanaka Akira
  0 siblings, 0 replies; 11+ messages in thread
From: Tanaka Akira @ 1999-07-22  7:32 UTC (permalink / raw)
  To: zsh-workers

In article <199907220718.JAA03731@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> Tanaka, could you try it? (Does it SEGV in callcompfunc() now?)

Thanks. The patch fix the problem.
-- 
Tanaka Akira


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: core dump with completion.
@ 1999-07-22  7:18 Sven Wischnowsky
  1999-07-22  7:32 ` Tanaka Akira
  0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 1999-07-22  7:18 UTC (permalink / raw)
  To: zsh-workers


Tanaka Akira wrote:

> zsh dumps core with completion with following operation.
> 
> Script started, file is typescript
> $ ls
> 7196              7217              7230              share
> 7202              7218              7231              typescript
> 7205              7219              7235              u2456
> 7209              7220              7241              zsh-3.1.6-test-2
> 7210              7223              bin
> 7213              7226              lib
> 7216              7229              man
> $ bin/zsh -f
> is27e1u11% bindkey -e; autoload -U compinit; compinit
> is27e1u11% cvs add <TAB><C-c>
> is27e1u11% A=sh<TAB>zsh: segmentation fault (core dumped)  bin/zsh -f
> $ Script done, file is typescript

This looked so much like 6814, that I made the patch below even though 
I couldn't reproduce it either (and this time neither on the DEC box,
nor on my Linux-Laptop). The patch isn't dangerous, so should probably 
be applied even if Tanaka says that it doesn't fix the bug.

Tanaka, could you try it? (Does it SEGV in callcompfunc() now?)

If we still get the bug, I'd be interested in the values stored in the 
owords arrays in previous stack frames of comp_wrapper() -- and in the 
values of clwords, clwsize, clwnum, and clwpos.

Hm, can't think of more just now...

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Tue Jul 20 11:36:54 1999
+++ Src/Zle/zle_tricky.c	Thu Jul 22 09:10:19 1999
@@ -4610,8 +4610,11 @@
 		kset |= CP_PARAMETER;
 		if (!clwpos) {
 		    clwpos = 1;
+		    clwnum = 2;
 		    zsfree(clwords[1]);
 		    clwords[1] = ztrdup(s);
+		    zsfree(clwords[2]);
+		    clwords[2] = NULL;
 		}
 		aadd = 1;
 		break;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2000-01-28 16:26 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-21 15:50 core dump with completion Tanaka Akira
1999-07-21 15:49 ` Peter Stephenson
1999-07-21 16:14 ` Bart Schaefer
1999-07-21 17:02   ` Tanaka Akira
1999-07-22  7:18 Sven Wischnowsky
1999-07-22  7:32 ` Tanaka Akira
2000-01-26  7:45 Tanaka Akira
2000-01-26 10:09 Sven Wischnowsky
2000-01-26 11:54 ` Tanaka Akira
2000-01-28 13:55 Sven Wischnowsky
2000-01-28 16:26 ` Tanaka Akira

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).