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

Submitter:  Paul van Tilburg <paulvt>
Submitted:  Sun 07 Oct 2007 09:54:19 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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 Files:
   
   
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
  • -email is unavailable- added by dickey (Posted a comment)
  • -email is unavailable- added by paulvt (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-09-09 dickey StatusNone Fixed
    2007-10-11 dickey Attached File- Added vile-9.5r-varargs.patch, #14134
    2007-10-11 paulvt Attached File- Added vile-crash.log, #14132

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code