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

[Thomas Dickey]

On Sat, 5 Sep 2009, Clem Taylor wrote:

> On Fri, Sep 4, 2009 at 6:07 PM, Thomas Dickey<address@hidden> wrote:
> > that's the first user of "reflex" that I've seen.
>
> vile wouldn't compile with flex 2.5.35, so I used reflex instead.

;-)

Aside from code-cleanup, the main change in reflex (so far) is that (for 
8-bit character sets), it happens to compile-in the proper character-type 
in the yy_ec[] table.  That makes lexers able to handle Latin-1, etc., in 
things like [[:alnum:]].

I'm working on a change now that would let me change that compiled-in 
character information for other 8-bit character sets.  (UTF-8 is not
there yet ;-)

> > hmm.  I vaguely recall some comment like that, but haven't _seen_ it myself.
>
> On the other systems I have 9.5[rl] which don't seem to have this problem.
> > That's interesting - are you editing the [HighlightClear] buffer?
>
> I wasn't. I seem to be able to reproduce the problem just typing out a
> hello world program making many mistakes, but I haven't been able to
> come up with what the combination is needed it trigger the problem. It
> seems to be easier to trigger it over an ssh connection (with a slow
> link).

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

> > To test that quickly, I'd suggest just changing line 4619 to "#if 0"
> > and see if I could reproduce the problem easily.
> >
> > I'm looking at this line:
> >
> >        if (!waiting && !im_timing && ShowWorking())
> >
> > and seeing that "!waiting" would be true after a call from input.c line 572:
> >
> >        (void) im_waiting(FALSE);
>
> I tried that and it and it still fails, but now it doesn't print
> "working...". I've managed to trigger the bug multiple times with the

that's useful information (I was thinking that most of the behavior
issues were in that path).

> 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.

> chg_buff (bp=0x7c67b0, flag=4) at buffer.c:2808
> 2808        if (update_on_chg(bp))
> (gdb) where
> #0  chg_buff (bp=0x7c67b0, flag=4) at buffer.c:2808
> #1  0x00000000004374e7 in ldel_bytes (nbytes=1, kflag=1) at line.c:757
> #2  0x000000000044f40c in killregionmaybesave (save=1) at region.c:219
> #3  0x0000000000443a21 in vile_op (f=0, n=1, fn=0x44ff90 <killregion>,
>    str=0x4c521b "Delete") at opers.c:124
> #4  0x0000000000444343 in operdel (f=8153008, n=4) at opers.c:149
> #5  0x0000000000423c5d in execute (execfunc=0x4cf9e0, f=4, n=2) at exec.c:1076
> #6  0x0000000000406cac in main_loop () at main.c:1013
> #7  main () at main.c:920

They all seem to be in the same place - a loop in ldel_bytes().

Looking at that function now, I'm seeing that the loop is like this:

    while (nbytes != 0) {
        dotp = DOT.l;
        doto = DOT.o;
...
        uchunk = (B_COUNT) (llength(dotp) - doto);      /* Size of chunk.  */
        if (uchunk > nbytes)
            uchunk = nbytes;
...
        nbytes -= uchunk;
    }

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.

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