More trap-handling crashes

More trap-handling crashes

[Bart Schaefer]

The quickest way to see it is as follows:

zagzig[81] Src/zsh -f
zagzig% autoload -U promptinit
zagzig% promptinit
zagzig% prompt bart
zagzig [prompt bart] /usr/src/local/zsh/zsh-3.1.9-build        00-06-10 10:49AM
zagzig% prompt bart off
(zsh consumes all available memory, then crashes)

The problem is that here:

#0  dosavetrap (sig=28, level=3) at ../../zsh-3.1.6/Src/signals.c:675
#1  0x809312f in removetrap (sig=28) at ../../zsh-3.1.6/Src/signals.c:756
#2  0x8093080 in unsettrap (sig=28) at ../../zsh-3.1.6/Src/signals.c:733
#3  0x8092fb1 in settrap (sig=28, l=0x8124c10)
    at ../../zsh-3.1.6/Src/signals.c:700
#4  0x80a613f in setfunction (name=0x400e23d8 "TRAPWINCH", val=0x8124bc8 "", 
    dis=0) at ../../../zsh-3.1.6/Src/Modules/parameter.c:357
(More stack frames follow...)

sigfuncs[sig] points to a completely garbaged eprog with a huge `len' field,
so zsh tried to allocate roughly a gigabyte of memory.

localtraps is not set, and there's no exit trap involved.  I suspect this
is related to the (root cause of the) TRAPEXIT crash that Clint patched
recently.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: More trap-handling crashes

[Bart Schaefer]

On Jun 10,  6:22pm, Bart Schaefer wrote:
} Subject: More trap-handling crashes
}
} The quickest way to see it is as follows:
} 
} zagzig% prompt bart off
} (zsh consumes all available memory, then crashes)
} 
} localtraps is not set, and there's no exit trap involved.

I take it back:  Localtraps *IS* set, because `prompt' calls `emulate -L'.

} I suspect this is related to the (root cause of the) TRAPEXIT crash
} that Clint patched recently.

I'm now completely convinced that the two are connected, and that testing
for (st->list != NULL) is not a sufficient fix.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: More trap-handling crashes

[Bart Schaefer]

On Jun 10,  6:56pm, Bart Schaefer wrote:
}
} On Jun 10,  6:22pm, Bart Schaefer wrote:
} } I suspect this is related to the (root cause of the) TRAPEXIT crash
} } that Clint patched recently.
} 
} I'm now completely convinced that the two are connected, and that testing
} for (st->list != NULL) is not a sufficient fix.

I've traced this to the point where parse.c:bld_eprog() does something
horribly wrong when handed a parse consisting of nothing but NULLTOK,
and now I'm beyond my understanding of what's supposed to be going on.

However, it sure looks like a bad interaction between the trap scoping
mechanism and eprogs for functions with empty bodies.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net