Bug 430375 - /bin/vi memory problem - core dump
/bin/vi memory problem - core dump
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: vim (Show other bugs)
8
All Linux
low Severity urgent
: ---
: ---
Assigned To: Karsten Hopp
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-26 22:18 EST by JW
Modified: 2008-01-30 06:40 EST (History)
0 users

See Also:
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 06:40:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description JW 2008-01-26 22:18:19 EST
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 06:25:37 EST
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 06:40:45 EST
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.


Note You need to log in before you can comment on or make changes to this bug.