Bug 430375

Summary: /bin/vi memory problem - core dump
Product: [Fedora] Fedora Reporter: JW <ohtmvyyn>
Component: vimAssignee: Karsten Hopp <karsten>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 8   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: vim-7.1.211-1.fc8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-30 11:40:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description JW 2008-01-27 03:18:19 UTC 
Description of problem:
Under fairly normal circumstances /bin/vi will core dump because of memory
corruption

Version-Release number of selected component (if applicable):
vim-minimal-7.1.135-1

How reproducible:
Whenever it happens.

Steps to Reproduce:
1. /bin/vi somefile
2.
3.
  
Actual results:
*** glibc detected *** vi: double free or corruption (!prev): 0x0952edb0 ***

#0  0x0012d402 in __kernel_vsyscall ()
#1  0x0019aac6 in kill () from /lib/libc.so.6
#2  0x080a0ac7 in ?? ()
#3  0x080a0f56 in ?? ()
#4  0x08081108 in ?? ()
#5  <signal handler called>
#6  0x0012d402 in __kernel_vsyscall ()
#7  0x0019a690 in raise () from /lib/libc.so.6
#8  0x0019bf91 in abort () from /lib/libc.so.6
#9  0x001d29eb in __libc_message () from /lib/libc.so.6
#10 0x001daac1 in _int_free () from /lib/libc.so.6
#11 0x001de0f0 in free () from /lib/libc.so.6
#12 0x080bebe3 in ?? ()
#13 0x080bec2a in ?? ()
#14 0x080bf40a in ?? ()
#15 0x08083d90 in ?? ()
#16 0x08096e63 in ?? ()
#17 0x0808f464 in ?? ()
#18 0x08093caf in ?? ()
#19 0x08071c48 in ?? ()
#20 0x0807304c in ?? ()
#21 0x00187390 in __libc_start_main () from /lib/libc.so.6
#22 0x08049f51 in ?? ()


Expected results:
Should not core dump.

Additional info:
This is new behavior either in vim-minimal or glibc.
Comment 1 JW 2008-01-27 11:25:37 UTC 
With unstripped binary the following stack trace is produced:
(gdb) bt

#0  0x0012d402 in __kernel_vsyscall ()
#1  0x0017fac6 in kill () from /lib/libc.so.6
#2  0x080a0987 in may_core_dump () at os_unix.c:2949
#3  0x080a0e16 in mch_exit (r=1) at os_unix.c:2914
#4  0x08080fb8 in preserve_exit () at misc1.c:8349
#5  <signal handler called>
#6  u_freeheader (buf=0x84d2b20, uhp=0x84db128, uhpp=0xbfba22f8) at undo.c:1653
#7  0x080bf18a in u_savecommon (top=1, bot=3, newbot=0) at undo.c:425
#8  0x080bf5b0 in u_save_cursor () at undo.c:218
#9  0x0804ea9c in stop_arrow () at edit.c:6232
#10 0x08051456 in insert_special (c=35, allow_modmask=0, ctrlv=0)
    at edit.c:5367
#11 0x080520fd in edit (cmdchar=105, startln=0, count=1) at edit.c:1381
#12 0x0808f6dd in invoke_edit (cap=0xbfba2408, repl=0, cmd=105, startln=0)
    at normal.c:8737
#13 0x08093b24 in normal_cmd (oap=0xbfba2460, toplevel=1) at normal.c:1141
#14 0x08071b08 in main_loop (cmdwin=0, noexmode=0) at main.c:1181
#15 0x08072f0c in main (argc=0, argv=0x23) at main.c:940
Comment 2 Karsten Hopp 2008-01-30 11:40:45 UTC 
Please update to the latest vim package for F-8 (vim-7.1.211-1.fc8) and try to
reproduce this bug.
If it still exists, please reopen this bugreport.