vile
[Top][All Lists]
Advanced

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

Re: [vile] Here is the file which demonstrates the insert bug


From: Thomas Dickey
Subject: Re: [vile] Here is the file which demonstrates the insert bug
Date: Wed, 23 Apr 2008 18:49:54 -0400
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Wed, Apr 23, 2008 at 10:52:02PM +0100, Chris G wrote:
> On Wed, Apr 23, 2008 at 10:46:15PM +0100, Chris G wrote:
> > On Wed, Apr 23, 2008 at 10:35:28PM +0100, Chris G wrote:
> > > On Wed, Apr 23, 2008 at 04:00:44PM -0400, Thomas Dickey wrote:
> > > > On Wed, 23 Apr 2008, Chris G wrote:
> > > >
> > > > The problem was that 'cnt' is supposed to be a character count rather 
> > > > than
> > > > a byte-count, but it was computed there as a byte-count.
> > > >
> > > I'm afraid that hasn't fixed my bug, it still hangs and says
> > > "working..." alternating with "...working".
> > > 
> > I've built vile with --with-trace and have attached the Trace.out
> > file.
> > 
> > (... and this time I have remembered to attach it!)
> > 
> .... but it's too big!  Try again with the last part of the trace.

I can see the general outline of what's happening, but not enough
detail.  What I did to isolate the problem that I _did_ find was
to sprinkle the code with additional Trace's (which is why it took
an hour).  Simple stuff like this, that I could see where I'd gotten
to in the code versus in the edited file:

  Trace("address@hidden @%d.%d\n", __FILE__, __LINE__, line_no(curbp, DOT.l), 
DOT.o);

ONE quick thing to check - I'd verify that the 'working' mode itself
is not related to the problem.  It's been a while since we had problems
with it, since I bracketed the places where we do malloc's with
beginDisplay/endofDisplay.  But perhaps there's some vulnerability with
iconv which isn't visible on my system.

I've pruned out the repetitive part below, to show what's visible:

this is one cycle of 'x' - deleting a character

> converted 0 'x' -> 79:0x78
> vl_mb_getch:0x78
> mapped/getc:x (0x78)
> kcod2prc(0x78) ->x
> tgetc(unquoted) = x
> called {{ execute(execfunc=0x49c8a0(func:forwdelchar), f=0, n=1)
> | called {{ execute(execfunc=0x49c960(func:forwchar_to_eol), f=0, n=1)
> | | return }} 1
> | called {{ freeundostacks(0x6f43a0,0)
> | | return }} 
> | return }} 1
> called {{ update(0)
> | CURSOR OFF
> | called {{ update_physical_screen(0)
> | | return }} 
> | CURSOR ON
> | return }} 1

Here's where the insert begins.  Note the special_formatter call, which
shows the 'I' in the insert-mode:

> converted 0 'i' -> 79:0x69
> vl_mb_getch:0x69
> mapped/getc:i (0x69)
> kcod2prc(0x69) ->i
> tgetc(unquoted) = i
> called {{ execute(execfunc=0x49d360(func:insert), f=0, n=1)
> | called {{ update(0)
> | | CURSOR OFF
> | | called {{ special_formatter %-%i%- %b %m:: :%f:is : :%=%F: : 
> :%l:(:,:%c::) :%p::% :%C:char ::%S%-%-%|
> | | | shorten '/home/chris/tmp/testBug'
> | | |      -> '/home/chris/tmp/testBug' shorten
> | | | shorten '/home/chris/tmp/testBug'
> | | |      -> '/home/chris/tmp/testBug' shorten
> | | | return }} 
> | | called {{ update_physical_screen(0)
> | | | return }} 
> | | CURSOR ON
> | | return }} 1

here's one cycle of 'i' (which looks as if you're typing i's):

> | converted 0 'i' -> 79:0x69
> | vl_mb_getch:0x69
> | mapped/getc:i (0x69)
> | kcod2prc(0x69) ->i
> | tgetc(unquoted) = i
> | called {{ freeundostacks(0x6f43a0,0)
> | | return }} 
> | called {{ update(0)
> | | CURSOR OFF
> | | called {{ update_physical_screen(0)
> | | | return }} 
> | | CURSOR ON
> | | return }} 1

after several characters, one causes wrapping:

> | converted 0 'i' -> 79:0x69
> | vl_mb_getch:0x69
> | mapped/getc:i (0x69)
> | kcod2prc(0x69) ->i
> | tgetc(unquoted) = i
> | called {{ update(0)
> | | CURSOR OFF
> | | called {{ special_formatter %-%i%- %b %m:: :%f:is : :%=%F: : 
> :%l:(:,:%c::) :%p::% :%C:char ::%S%-%-%|
> | | | shorten '/home/chris/tmp/testBug'
> | | |      -> '/home/chris/tmp/testBug' shorten
> | | | shorten '/home/chris/tmp/testBug'
> | | |      -> '/home/chris/tmp/testBug' shorten
> | | | return }} 
> | | called {{ update_physical_screen(0)
> | | | return }} 
> | | CURSOR ON
> | | return }} 1

only 7 more repetitions of 'i' follow past the wrapping point:

> | converted 0 'i' -> 79:0x69
> | vl_mb_getch:0x69
> | mapped/getc:i (0x69)
> | kcod2prc(0x69) ->i
> | tgetc(unquoted) = i
> | called {{ update(0)
> | | CURSOR OFF
> | | called {{ update_physical_screen(0)
> | | | return }} 
> | | CURSOR ON
> | | return }} 1

...and it dies somewhere before getting into update():

> | converted 0 'i' -> 79:0x69
> | vl_mb_getch:0x69
> | mapped/getc:i (0x69)
> | kcod2prc(0x69) ->i
> | tgetc(unquoted) = i

I'd expect that loop to be the calls on inschar() in ins_any_time().

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

Attachment: signature.asc
Description: Digital signature


reply via email to

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