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

[Thomas Dickey]

On Fri, 4 Sep 2009, Clem Taylor wrote:

> Hi,
>
> I'm a long time vile user and I recently switched to a new desktop
> machine and have been unable to build a working version of vile. I'm
> using a x86_64 Fedora 11 system with gcc 4.4.1 and I built vile with:
> ../configure LEX=reflex --with-builtin-filters=all

that's the first user of "reflex" that I've seen.

I made a change to it this week to add a patch-date to the version 
message, which needs a small fix to vile's configure script to recognize
that (a caution in case you update reflex before 9.7v).

> During normal use (typically inserting text or deleting a line) vile
> gets stuck in a "working..." "...working" loop. I saw mention of this
> problem in the list archive, but didn't notice a resolution:

hmm.  I vaguely recall some comment like that, but haven't _seen_ it 
myself.

> Here are a few stack traces:
> (gdb) where
> #0  0x0000000000437696 in ldel_bytes (nbytes=1, kflag=1) at line.c:803
> #1  0x000000000044f42c in killregionmaybesave (save=1) at region.c:219
> #2  0x0000000000443a41 in vile_op (f=0, n=1, fn=0x44ffb0 <killregion>,
> str=0x4c523b "Delete") at opers.c:124
> #3  0x0000000000444363 in operdel (f=8242432, n=0) at opers.c:149
> #4  0x0000000000423c7d in execute (execfunc=0x4cfa00, f=0, n=0) at exec.c:1076
> #5  0x0000000000406cac in main_loop () at main.c:1013
> #6  main () at main.c:920
>
> (gdb) where
> #0  0x0000000000402f40 in address@hidden ()
> #1  0x000000000040f8f8 in find_b_name (bname=<value optimized out>) at
> buffer.c:2531
> #2  0x000000000040f919 in update_scratch (name=0x87dfdc
> "[HighlightClear]", func=0x7fffffffdfec) at buffer.c:2263

That's interesting - are you editing the [HighlightClear] buffer?

> #3  0x00000000004104f5 in chg_buff (bp=0x7c0190, flag=57324) at buffer.c:2809
> #4  0x0000000000437507 in ldel_bytes (nbytes=1, kflag=1) at line.c:757
> #5  0x000000000044f42c in killregionmaybesave (save=1) at region.c:219
> #6  0x0000000000443a41 in vile_op (f=0, n=1, fn=0x44ffb0 <killregion>,
> str=0x4c523b "Delete") at opers.c:124
> #7  0x0000000000444363 in operdel (f=8904668, n=-8212) at opers.c:149
> #8  0x0000000000423c7d in execute (execfunc=0x4cfa00, f=-8212, n=0) at
> exec.c:1076
> #9  0x0000000000406cac in main_loop () at main.c:1013
>
> I've tried building 9.7t, and 9.7s, 9.7 and 9.7u (today) with the same
> failure. I also tried without builtin filters with the same results.
> It seems to fail the same way without my .vilerc.

Well, the timer is controlled over in display.c, and would be reset by
the stop_working() function, called from imworking().

start_working() is called from three places (in display.c of course).

Looking at the code, I'd suspect that if there's a logic/state problem,
it would be in the call from line 4621, in im_waiting(), e.g., something
like what Paul Fox reported regarding autocolor interrupting a prompt
for character input, and clobbering a flag.

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);

but in context, there's no check to ensure that there's no typeahead.
It might be that the problem is that it's not inside the block from
lines 563-570 for instance, which _might_ make a difference if you're
using a macro ^X-& or "."

(now I'll have to think about that...)

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