bugvile, a vi-compatible text editor - Bugs: bug #21282, The go-to-line commandline...

 
 

bug #21282: The go-to-line commandline parameter(s) crashes vile

Submitted by:  Paul van Tilburg <paulvt>
Submitted on:  Sun 07 Oct 2007 09:54:19 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Open

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 28 Oct 2007 11:28:07 PM UTC, comment #11:

thanks (the semantics of va_copy are not always obvious).

I've applied that to my ongoing 9.5s changes, am will make
a configure-check for older systems with no va_copy().

Thomas Dickey <dickey>
Project Administrator
Sun 28 Oct 2007 11:32:08 AM UTC, comment #10:

I can confirm that this patch fixes the problem.

Paul van Tilburg <paulvt>
Thu 11 Oct 2007 08:32:02 PM UTC, comment #9:

The arrangement of va_list in display.c has been "like that"
since early 2004. Since that point, there's been some
attention on va_copy() because it's a c99 feature which
happens to be needed in Mac OS X (where the implied equating
of va_list with a stack frame pointer doesn't hold).

Perhaps some aspect of that came into the support for PowerPC
more generally. That's just a guess.

I'm attaching a seems-to-work patch to display.c which uses va_copy(). If that fixes the problem, I'll add it to the
ongoing changes for 9.5s.

(file #14134)

Thomas Dickey <dickey>
Project Administrator
Thu 11 Oct 2007 07:54:38 PM UTC, comment #8:

There's not much to sieve through outside of this chunk which
implicates vile's use of varargs. I see now that the problem
may be that I may need to use va_copy() in b2vprintf(), since
it is b2printf() which does va_start/va_end, but passes the
va_list value down two levels to dofmt().

==3056== Use of uninitialised value of size 4
==3056== at 0x1002F4F0: dofmt (display.c:318)
==3056== by 0x1002F790: b2vprintf (display.c:3953)
==3056== by 0x1002F97C: b2printf (display.c:3977)
==3056== by 0x1001E3BC: setup_command (main.c:206)
==3056== by 0x1001EC44: main (main.c:495)
==3056==
==3056== Invalid read of size 4
==3056== at 0x1002F4F0: dofmt (display.c:318)
==3056== by 0x1002F790: b2vprintf (display.c:3953)
==3056== by 0x1002F97C: b2printf (display.c:3977)
==3056== by 0x1001E3BC: setup_command (main.c:206)
==3056== by 0x1001EC44: main (main.c:495)
==3056== Address 0x38002EF0 is not stack'd, malloc'd or (recently) free'd
==3056==
==3056== Invalid read of size 1
==3056== at 0xFFBC36C: strlen (mc_replace_strmem.c:246)
==3056== by 0x1002EF24: dfputsn (display.c:108)
==3056== by 0x1002F500: dofmt (display.c:318)
==3056== by 0x1002F790: b2vprintf (display.c:3953)
==3056== by 0x1002F97C: b2printf (display.c:3977)
==3056== by 0x1001E3BC: setup_command (main.c:206)
==3056== by 0x1001EC44: main (main.c:495)
==3056== Address 0x7C0802A6 is not stack'd, malloc'd or (recently) free'd

Thomas Dickey <dickey>
Project Administrator
Thu 11 Oct 2007 06:17:17 PM UTC, comment #7:

I have attached a crash log generated by valgrind.
Note that I also get a crash when I do something like:

% vile +adfasfadsfa <file>

(file #14132)

Paul van Tilburg <paulvt>
Wed 10 Oct 2007 09:59:23 PM UTC, comment #6:

yes, I'd like to try sieving through the warnings.

Thomas Dickey <dickey>
Project Administrator
Tue 09 Oct 2007 05:58:06 AM UTC, comment #5:

I am running it on Linux and I have valgrind. However, this is not set up properly on powerpc, since it also prints all the errors for libc6 which makes it a flood of errors/warnings. But if you want to sieve through that, let me know.

By the way, if I run the same vile the same way on x86, I get the buffer with the file, but also the Messages buffer. Is this normal behaviour?

Paul van Tilburg <paulvt>
Mon 08 Oct 2007 10:28:02 PM UTC, comment #4:

This is the "+" case, which is called from line 495 of main.c
But I don't see why it would be breaking. I can see that
the variables appear to be passed down properly. Since the
main effect of the change is to make it write into a buffer
before windows are normally setup, I suspect it's related to
that. If you have valgrind, it can be usually used to show
the reference to uninitialized memory, etc. Is this Linux
or one of the BSD's that you're running?

Thomas Dickey <dickey>
Project Administrator
Mon 08 Oct 2007 07:43:00 PM UTC, comment #3:

Here you go:

#0 0x1002f4f0 in dofmt (fmt=0x100a3e08 "\n", app=0x7fd7c338)
at ../../display.c:318
c = <value optimized out>
the_width = -1
the_limit = -1
n = 269106672
islong = 0
int_value = <value optimized out>
long_value = <value optimized out>
outfunc = (OutFunc) 0x1002fba0 <bputc>
#1 0x1002f794 in b2vprintf (bp=0x100e7918,
fmt=0x100a3df0 "execute-named-command %s\n", ap=0x7fd7c378)
at ../../display.c:3953
save_curgoal = -1
result = <value optimized out>
save_wp = (vile_WINDOW *) 0x100e5278
save_bp = (BUFFER *) 0x0
save_w_traits = {w_dt = {l = 0x100e7d40, o = 0}, w_ld = {l = 0x0,
o = 0}, w_tld = {l = 0x0, o = 0}, w_ln = {l = 0x100e7d40, o = 0},
insmode = 0, w_vals = {wv = {{v = {i = 1,
p = 0x1 <Address 0x1 out of bounds>, r = 0x1}, vp = 0x100d10d8}, {
v = {i = 0, p = 0x0, r = 0x0}, vp = 0x100d10e0}, {v = {i = 0, p = 0x0,
r = 0x0}, vp = 0x100d10e8}, {v = {i = 0, p = 0x0, r = 0x0},
vp = 0x100d10f0}, {v = {i = 0, p = 0x0, r = 0x0}, vp = 0x100d10f8}, {
v = {i = 0, p = 0x0, r = 0x0}, vp = 0x100d1100}, {v = {i = 0, p = 0x0,
r = 0x0}, vp = 0x100d1108}, {v = {i = 0, p = 0x0, r = 0x0},
vp = 0x100d1110}, {v = {i = 1, p = 0x1 <Address 0x1 out of bounds>,
r = 0x1}, vp = 0x100d1118}, {v = {i = 0, p = 0x0, r = 0x0},
vp = 0x100d1120}, {v = {i = 0, p = 0x0, r = 0x0}, vp = 0x100d1128}}},
w_left_dot = {l = 0x0, o = 0}, w_left_col = 0, w_left_adj = 0,
w_list_opt = 0, w_num_cols = 0}
save_outfn = (OutFunc) 0x1002ed10 <lspputc>
#2 0x1002f980 in b2printf (bp=0x7fd7c218, fmt=0x1 <Address 0x1 out of bounds>)
at ../../display.c:3977
ap = {{gpr = 2 '\002', fpr = 0 '\0', reserved = 61428,
overflow_arg_area = 0x7fd7c3e8, reg_save_area = 0x7fd7c380}}
#3 0x1001e3c0 in setup_command (opts_bp=0x100e7918, param=0x7fd7d8af "1")
at ../../main.c:206
p1 = 0x7fd7d8b0 ""
p2 = 0x7fd7d8b0 ""
#4 0x1001ec48 in main (argc=3, argv=0x7fd7d714) at ../../main.c:495
param = 0x7fd7d8ae "+1"
tt_opened = 1
bp = (BUFFER *) 0x100e2bc0
carg = 1
vileinit = 0x0
startstat = <value optimized out>
havebp = (BUFFER *) 0x0
init_bp = (BUFFER *) 0x100e74f0
opts_bp = (BUFFER *) 0x100e7918
havename = 0x0
startkey = '\0' <repeats 19 times>

Paul van Tilburg <paulvt>
Sun 07 Oct 2007 10:32:40 PM UTC, comment #2:

valgrind doesn't seem to show me anything - though the call stack looks plausible. valgrind does show some leaks, e.g.,

==13460== 16 bytes in 1 blocks are indirectly lost in loss record 2 of 4
==13460== at 0x4024765: malloc (vg_replace_malloc.c:149)
==13460== by 0x808C77E: lalloc (line.c:90)
==13460== by 0x808E0C5: linsert (line.c:383)
==13460== by 0x8062ECD: bputc (display.c:3903)
==13460== by 0x8064FB0: dofmt (display.c:119)
==13460== by 0x8065265: b2vprintf (display.c:3953)
==13460== by 0x8065351: b2printf (display.c:3977)
==13460== by 0x80507BE: main (main.c:426)

I tried with/without "foo" being a new file or old, against "9.5r" built with memory-leak checking. If it were a new file,
I thought it possible that there was some boundary error.
The leak shown is for the case where vile is adding the
"goto-line" command to a temporary buffer, which is executed
later. I have a hunch this is in the right area, but it's
not breaking for me.

(my post-9.5r changes have all been in other areas, so I've
not fixed this yet as far as I know).

A walkback with debug trace would help - valgrind is even
better.

Thomas Dickey <dickey>
Project Administrator
Sun 07 Oct 2007 09:56:11 AM UTC, comment #1:

This is vile 9.5(r) by the way. The bug appeared right after my upgrade from 9.5(i) to 9.5(r).

Paul van Tilburg <paulvt>
Sun 07 Oct 2007 09:54:19 AM UTC, original submission:

When using the go-to-line parameter (+NNN or -g NNN),
vile crashes (on my powerpc machine).

% vile -g 1 foo
[1] 20363 abort vile -g 1 foo

Trace (without debugging symbols):

#0 0x1002f4f0 in ?? ()
No symbol table info available.
#1 0x1002f148 in ?? ()
No symbol table info available.
#2 0x1002f794 in b2vprintf ()
No symbol table info available.
#3 0x1002f980 in b2printf ()
No symbol table info available.
#4 0x1001e3c0 in ?? ()
No symbol table info available.
#5 0x1001ec48 in main ()
No symbol table info available.

If you need more information, let me know!

Paul van Tilburg <paulvt>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #14134:  vile-9.5r-varargs.patch added by dickey (6KiB - text/x-patch)
file #14132:  vile-crash.log added by paulvt (314KiB - text/x-log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dickey (Posted a comment)
  • -unavailable- added by paulvt (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 09 Sep 2008 08:16:58 PM UTCdickeyStatusNone=>Fixed
    Thu 11 Oct 2007 08:32:02 PM UTCdickeyAttached File-=>Added vile-9.5r-varargs.patch, #14134
    Thu 11 Oct 2007 06:17:17 PM UTCpaulvtAttached File-=>Added vile-crash.log, #14132

    Back to the top


    Powered by Savane 3.1-cleanup1