Re: odd completion behavior

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On Sep 17,  1:01pm, Sven Wischnowsky wrote:
} Subject: Re: odd completion behavior
}
} (gdb) where
} #7  0x8063d4b in runshfunc (list=0x816ae30, wrap=0x0, 
}     name=0x81559a8 "_main_complete") at exec.c:3032
} #8  0x40198481 in comp_setunset () from /usr/lib/zsh/3.1.6-debian/compctl.so
} #9  0x8063cc8 in runshfunc (list=0x816ae30, wrap=0x4019a784, 
}     name=0x81559a8 "_main_complete") at exec.c:3019
} 
} We can't really trust this because it shows (inter alia) the same
} problem as the one from 7673: #8->#7 is impossible.
} 
} The weird strings made me think that this is a memory allocation
} problem with `compstate'.

If I had to guess, I'd say that the stack is getting trashed because
the VARARR() at exec.c:3019 is not allocating the right number of bytes.

That wouldn't show up in any of the zsh memory testing stuff because it
is using alloca() or the equivalent to create space on the stack, and
it would explain how the bogus frame #8 got stuck in there.

Could the global underscorelen be messed up at that point?

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