[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 15:22:33 -0400 (EDT)

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

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

reply via email to

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