Re: [vile] vile-9.7[stu] gets stuck "working..."

[Thomas Dickey]

On Sat, 5 Sep 2009, Clem Taylor wrote:

> > hmm - then I might try to reproduce it by slowing down vile (or the
> > terminal).
>
> All the gdb results in my last message where on the local machine, not via ssh.
>
> > > same process: open up a file, split the window, create a new file,
> > > copy 5 or so lines from the first file, paste them in the new file,
> > > goto the first line of the new file and delete it with 'dd'.
> >
> > "paste" here sounds like outside vile (select/paste in X for instance).
> > I tend to just use 'q' to select, but that bypasses a lot of I/O.
>
> This was purely in vile: 5yy, switch buffers, p :1 dd

maybe I'd see it in valgrind (that seems to work w/o problem).

> > The exact form of the loop I did change last winter, for compiler-warnings
> > (as part of fixes to separate signed/unsigned computations).
> >
> > Perhaps somewhere there's an off-by-one that's making nbytes never reach
> > zero.  I'd "up" in the debugger to ldel_bytes and inspect the nbytes
> > and uchunk values.
>
> nbytes seems to stay 1, I tried watching nbytes but gdb didn't seem to
> like that, so I recompiled without -O2 and I haven't been able to
> trigger the bug again. Will keep trying...

assert's help in that case - for instance, saving the old value of
nbytes at the top of the loop, then then checking after subtracting
ubytes that nbytes has decreased:

#include <assert.h>

            while (nbytes != 0) {
                B_COUNT oldnbytes = nbytes;
...
                nbytes -= line_length(nlp);
                assert(oldnbytes >= nbytes);
...
        nbytes -= uchunk;
        assert(oldnbytes > nbytes);
    }

I indicated ">=" in the first one since it is immediately followed by
moving to a new line in that case.

Anyway, the assert would give a nice core dump on the first time the
problem occurred, possibly making it easier to inspect the variables.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net