[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Dickey
Subject: Re: [vile] vile-9.7[stu] gets stuck "working..."
Date: Sat, 5 Sep 2009 16:01:23 -0400 (EDT)

On Sat, 5 Sep 2009, Clem Taylor wrote:

hmm - then I might try to reproduce it by slowing down vile (or the

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]