On 2017/08/24 17:42, Jeremie Courreges-Anglas wrote:
> On Wed, Aug 23 2017, Stuart Henderson <[email protected]> wrote:
> > On 2017/08/15 11:57, Jeremie Courreges-Anglas wrote:
> >> CVSROOT:   /cvs
> >> Module name:       src
> >> Changes by:        [email protected]    2017/08/15 11:57:57
> >> 
> >> Modified files:
> >>    bin/ksh        : alloc.c 
> >> 
> >> Log message:
> >> Remove expensive pointer check in afree()
> >> 
> >> The check added in rev 1.8 walks the whole freelist to catch cases where
> >> an unknown pointer is passed to afree(); but it can't catch cases
> >> whether the struct link has been corrupted by an invalid memory write.
> >> And it becomes very expensive when you have lots of items in an area
> >> (for example with a huge HISTSIZE).
> >> 
> >> Discussed with & ok millert@ tb@
> >> 
> >
> > I'm not certain that it's a result of this change, but I updated to a
> > snapshot past this change yesterday and today in one of my open shells
> > I started getting "ksh: history file is corrupt" showing up when trying
> > to run any commands (the command is then not executed). Opening a new
> > terminal I get a hang (interruptable with ^C):
> >
> > load: 0.38  cmd: ksh 2244 [lockf] 0.02u 0.02s 0% 243k
> >
> > My histfile is currently 1197 lines:
> >
> > $ wc .ksh_history 
> >     1197   12866  274756 .ksh_history
> >
> > Some of them are fairly long lines (e.g. 4096, 8465, 8482, 8345 chars)
> > and I probably haven't had quite such long lines before since the switch
> > to the plain history file, so if it's connected with that, it could also
> > have been a problem prior to the recent change and I just didn't run into
> > it before.
> 
> An overlong (>= 4096) line will result in the "ksh: history file is
> corrupt" warning, cvs says that this behavior was introduced with the
> current plaintext history file support. But it shouldn't result in hung
> interactive shell processes.  Could you please track this down to
> a short histfile that you could share?

I've been trying to re-trigger the hang this evening, I got it once
with the untrimmed history file that I'd backed up, but haven't repeated
it with any trimmed one, or the untrimmed one again now. Given the wchan
"lockf" I think this must have been in the history_lock() loop? Perhaps
there was a broken ksh process holding onto the file in a terminal that
I've since closed..

These long command lines aren't *all* that unusual if you've pasted
a cc/linker command into fc and are fiddling with parameters trying to
figure out how to build a recalcitrant port :)

Reply via email to