Purified zsh-3.0.1

[Hrvoje Niksic <hniksic@xxxxxxx>]

I have run a purified version of zsh-3.0.1 on solaris2.5, and here is
what I got:

1)
ABR: Array bounds read

This is in refreshline [zle_refresh.c:583]:
               /* 3: main display loop - write out the buffer using whatever tricks we can */
               
                   for (;;) {
            =>         if (*nl && nl[1] == ol[1])      /* skip only if second chars match */
                       /* skip past all matching characters */
                           for (; *nl && (*nl == *ol); nl++, ol++, ccs++) ;

The call chain was:
            refresh        [zle_refresh.c:398]
            zleread        [zle_main.c:487]
            inputline      [input.c:264]
            ingetc         [input.c:220]
            hgetc          [hist.c:109]

It is obviously an off-by-one error (as Purify would have it, "Reading
1 byte from 0x157019 in the text section.".
I got that when I tried various expansions, e.g. ls **/*<TAB>, or
pressing C-u, and similar.

Other than that, I encountered no ABR-s (or ABW-s), except the one
with max_fds & co., but that has been fixed.

However, there were many memory leaks.  All of these I got before ever
reaching the command-line -- only while executing startup scripts.

2) MLK
         MLK: 344 bytes leaked in 2 blocks
         This memory was allocated from:
               malloc         [rtlib.o]
               zalloc         [mem.c:315]
               metafy         [utils.c:2918]
               createparamtable [params.c:115]
               setupvals      [init.c:600]
               main           [init.c:66]
         Block of 256 bytes at 0x192b18
         Block of 88 bytes at 0x191df8

It seems that memory allocated in line 115 of params.c:
                 if ((!(pm = (Param) paramtab->getnode(paramtab, iname)) ||
                      !(pm->flags & PM_DONTIMPORT)) &&

never gets freed.

3) MLK
Another leak of 344 bytes.  Backtrace follows:
         MLK: 344 bytes leaked in 2 blocks
         This memory was allocated from:
               malloc         [rtlib.o]
               zalloc         [mem.c:315]
               zjoin          [utils.c:1442]
               arrfixenv      [params.c:1778]
               colonarrsetfn  [params.c:1330]
               setstrvalue    [params.c:783]
         Block of 256 bytes at 0x1932e8
         Block of 88 bytes at 0x192100

Here it seems that the result of zjoin() was never freed, or the
retval of arrfixenv.

4) MLK
A similar leak, again.
         MLK: 344 bytes leaked in 2 blocks
         This memory was allocated from:
               malloc         [rtlib.o]
               zalloc         [mem.c:315]
               zjoin          [utils.c:1442]
               colonarrgetfn  [params.c:1318]
               getstrvalue    [params.c:699]
               getsparam      [params.c:956]
         Block of 256 bytes at 0x193590
         Block of 88 bytes at 0x192258

5) MLK
This one is in execcmd, which is not well:
         MLK: 33 bytes leaked in 2 blocks
         This memory was allocated from:
               malloc         [rtlib.o]
               zalloc         [mem.c:315]
               ztrdup         [mem.c:387]
               addvars        [exec.c:1099]
               execcmd        [exec.c:1253]
               execpline2     [exec.c:801]
         Block of 30 bytes at 0x18d720
         Block of 3 bytes at 0x1a2338

In addvars() pm = setsparam(v->name, ztrdup(val)); never gets freed, I
suppose (if errflag is set?).


I hope this will help debugging...  Those ABR-s in line editor could
be the cause of coredumps seen on Ultrix, that are quite hard to
repeat.

-- 
Hrvoje Niksic <hniksic@xxxxxxx> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!