Bug 138942 - double free or corruption: 0x082f7d50
Summary: double free or corruption: 0x082f7d50
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: vim
Version: 3
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-12 00:48 UTC by james
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-09-08 12:00:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
This is renamed .vimcrash.test.swp (12.00 KB, application/octet-stream)
2004-12-21 01:32 UTC, Bob Gustafson
no flags Details
vim swap file which generates ABRT (24.00 KB, application/octet-stream)
2005-02-16 19:45 UTC, james
no flags Details
strace log file for vim recover showing sig ABRT (67.10 KB, application/octet-stream)
2005-02-16 19:52 UTC, james
no flags Details

Description james 2004-11-12 00:48:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; Linux i686; U) Opera 7.54  [en]

Description of problem:
 # vim -r .text.swp

 Using swap file ".text.swp"
 Original file "/home/james/text"
 *** glibc detected *** double free or corruption: 0x082f7d50 ***
                                                                  
Recovery completed. You should check if everything is OK.
 (You might want to write out this file under another name
 and run diff with the original file to check for changes)
 Delete the .swp file afterwards.

 Vim: Caught deadly signal ABRT

"kill -9 nnnn" is required to recover the terminal prompt.

Same problem with either /lib/libc or /lib/tls/libc.


Version-Release number of selected component (if applicable):
vim-enhanced-6.3.030-3

How reproducible:
Always

Steps to Reproduce:
1. swap file dependent
2. vim <file> or vim -r .<file>.swp
3.
    

Additional info:

libc is /lib/libc-2.3.3.so or /lib/tls/libc-2.3.3.so

ldd /usr/bin/vim
        linux-gate.so.1 =>  (0xffffe000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x07e0a000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7fb4000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7fae000)
        libgpm.so.1 => /usr/lib/libgpm.so.1 (0xb7fa9000)
        libperl.so => /usr/lib/perl5/5.8.5/i386-linux-thread-multi/
CORE/libperl.so (0xb7e73000)
        libutil.so.1 => /lib/libutil.so.1 (0xb7e6f000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7d49000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7d25000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7d21000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7d0f000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7d0b000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xb7cf5000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7cc7000)
        /lib/ld-linux.so.2 (0xb7feb000)

Comment 1 Karsten Hopp 2004-11-15 14:15:58 UTC
What's the version of your glibc ?
I cannot reproduce this with vim-enhanced-6.3.030-3 and
glibc-2.3.3-73

Comment 2 james 2004-11-15 20:24:44 UTC
I just upgraded to glibc-2.3.3-74.  I'm still getting the same error 
with this particular swap file.  Perhaps the swap file is corrupt in 
some interesting way?  Or could the kernel have anything to do here?  
I'm running 2.6.9-rc3.

Running inside strace gives, in part:
...
_llseek(3, 122880, [122880], SEEK_SET)  = 0
read(3, "ad\0\0 \0\0\0`\1\0\0\0\20\0\0K\0\0\0\274\17\0\0\256\17"..., 
4096) = 4096
_llseek(4, 8192, [8192], SEEK_SET)      = 0
write(4, "ad\0\0\22\0\0\0v\1\0\0\0\20\0\0T\0\0\0\266\17\0\0o\17\0"...
, 4096) = 4096
select(1, [0], NULL, [0], {0, 0})       = 0 (Timeout)
_llseek(3, 131072, [131072], SEEK_SET)  = 0
read(3, "ad\0\0\213\n\0\0\363\n\0\0\0\20\0\0\25\0\0\0\264\17\0\0"..., 
4096) = 4096
close(3)                                = 0
writev(2, [{"*** glibc detected *** ", 23}, {"double free or 
corruption", 25}, {": 0x082f9cd8 ***\n", 17}], 3) = 65
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
...



Comment 3 Bob Gustafson 2004-12-18 20:25:52 UTC
I get more or less the same problem

[root@hoho2 oops]# vim -r testo.txt
Vim: Caught deadly signal ABRT

The only way to get out is to open another window and do a kill -9

It may be related to the way the original vim died. Not by itself, but
perhaps by rebooting while vim was open in another window or through
vnc. Have not tested in any detail, but it does happen often..

Comment 4 Bob Gustafson 2004-12-18 20:28:23 UTC
Once the problem shows itself, the swap file must be deleted before
you can go into the file with the same name as the swap prefix.

Comment 5 Bob Gustafson 2004-12-18 20:30:51 UTC
Using Fedora3 with curent updates.  i686

[root@hoho2 oops]# vim --version
VIM - Vi IMproved 6.3 (2004 June 7, compiled Oct 19 2004 17:17:57)
Included patches: 1-21, 23-24, 26, 28-30
Modified by <bugzilla>
Compiled by <bugzilla>
Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset
+cindent
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments
+cryptv +cscope +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval
+ex_extra +extra_search +farsi +file_in_path +find_in_path +folding
-footer
+fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap
+langmap
 +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
+modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm
+mouse_netterm +mouse_xterm +multi_byte +multi_lang -netbeans_intg
-osfiletype
+path_extra +perl +postscript +printer +python +quickfix +rightleft -ruby
+scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse
+textobjects +title -toolbar +user_commands +vertsplit +virtualedit
+visual
+visualextra +viminfo +vreplace +wildignore +wildmenu +windows
+writebackup
-X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/share/vim"
Compilation: i386-redhat-linux-gcc -c -I. -Iproto -DHAVE_CONFIG_H    
-O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64   -D_REENTRANT -D_GNU_SOURCE
-DTHREADS_HAVE_PIDS -DDEBUGGING  -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm 
-I/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE 
-I/usr/include/python2.3 -pthread
Linking: i386-redhat-linux-gcc   -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE  
-L/usr/local/lib -o vim       -lncurses -lselinux  -lacl -lgpm -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE 
-L/usr/local/lib
/usr/lib/perl5/5.8.5/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE -lperl -lutil -lc
-L/usr/lib/python2.3/config -lpython2.3 -lutil -lm -Xlinker
-export-dynamic
[root@hoho2 oops]#



Comment 6 Sitsofe Wheeler 2004-12-19 22:53:33 UTC
Assuming the swap file doesn't contain anything sensitive, could you attach it to this bug?

Comment 7 Bob Gustafson 2004-12-21 01:32:42 UTC
Created attachment 108926 [details]
This is renamed .vimcrash.test.swp

[user1@hoho2 ~]$ more vimcrash.test
In theory, all I have to do is exit this file ungracefully,
like for example, rebooting while the file is open.

Now, the question is whether I need to be in INSERT mode, or
whether just having it open will do the trick.

I will just have it open to test this.

After closing insert mode, I will write out the file with :w
and then reboot system and look for the swp file..

Wish me luck.

---- OK, did not work.

Will try keeping the INSERT mode open and then reboot.

This is extra stuff which should be in the swp file - not saved.

--- OK, created swp file and it was on the disk when I rebooted
(Had to power cycle to reboot. After going part way down using the menu,
computer hung with the Fedora logo on screen - but mouse would not move,
could not get control. Long press on the power button, then a short press
to bring up machine.

On boot, I opened this file with the command 'vim vimcrash.test',
i.e., without using the -r recover argument. It came up with an
info sheet and asked whether I wanted to recover. I said 'r' and
this file came up perfectly - no crash..

Hmm - all of these experiments have been at user1 level, not root. Will
go to root and see if that makes a difference.

So, will exit this file, do a su to root and then reopen it, save it,
put it into insert mode, type a few characters, then reboot.

-- OK, root - I forgot to delete the 'good' swp file, so an info sheet
came up and I selected 'D' for delete. All normal good stuff.

-- Soon now - will reboot

Hmm, even though the swp file is owned by root, the 'r' recover selection
worked fine - no hang or crash.

Sorry, cannot get it to hang or crash. Will send you this file and the
swp file, but... Will watch for next time - and will capture the thing
a bit better.
---
The attached file is renamed from .vimcrash.test.swp to vimcrash.test.swp I
forgot what trick was used to be able to show dot files in the browser file
selection window. (Maybe I cannot get there once I have opened this page?)

Comment 8 Sitsofe Wheeler 2005-01-07 12:47:32 UTC
Try as I might I couldn't reproduce the problem with the attached swap file. Bob, can you reproduce the problem by downloading the attachment and doing vim -r on it?

Comment 9 james 2005-02-16 19:45:15 UTC
Created attachment 111134 [details]
vim swap file which generates ABRT

This test file should show the sig ABRT behavior.  Rename the file with a
leading "point" instead of the leading "comma".  This file was generated by
running vim in a KDE Konsole shell on a KDE desktop and then selecting "Logout"
from the KDE menu while vim was still running - it seems to take a couple of
tries.	I'll attach the  strace log bellow.

Comment 10 james 2005-02-16 19:52:44 UTC
Created attachment 111135 [details]
strace log file for vim recover showing sig ABRT

This is the strace log file for the vim session attempting to recover the above
",testabrt.swp" file.  The session has not yet fully ended and will require a
"kill -9" to fully terminate.  A Konsole shell will require a "reset" to
recover the terminal display.

Comment 11 james 2005-02-16 19:56:50 UTC
The swap and strace log files above were generated using 
vim-enhanced-6.3.054-0.fc3.1

Comment 12 Sitsofe Wheeler 2005-02-16 23:16:06 UTC
Can't reproduce the abort behaviour although valgrind does report two "jump or
move depends on uninitialised value" errors. Depressingly, installing the
vim-debuginfo package did not help valgrind give a more detailed error location.
An attempt to build vim from the SRPM and leave it uninstalled but compiled (and
thus with debug symbols) resulted in these errors mysteriously not appearing
(maybe it was built differently?)

Comment 13 Karsten Hopp 2005-09-08 12:00:04 UTC
Still not reproducable (vim-6.3.086). Please reopen when you can provide a
reproducable testcase

Comment 14 james 2005-09-09 13:58:40 UTC
Some more information - with respect to Sitsofe's "errors mysteriously not
appearing", there is also this:  At Bram's suggestion, I compiled vim to use
libefence, the Electric Fence Malloc Debugger.  Recovering the difficult swap
file with "EF_PROTECT_FREE=1 src/vim63/src/vim xorg.conf" produces a file
containing "???MANY LINES MISSING", but vim does not crash.  Better, recovering
the difficult swap file with "EF_PROTECT_FREE=1 EF_PROTECT_BELOW=1
src/vim63/src/vim xorg.conf" produces a file identical with a file that had been
recovered on a machine with Pentium hardware and on a machine with K6 hardware,
with no Electric Fence violation, and no gdb signals.  Again, errors now
mysteriously disappear when being watched with debugging tools.

Maybe this has something to do with the Athlon and some subtle shortcomings of
valgrind and efence?  "jump or move depends on uninitialised value" seems to be
the most specific information so far.

You did all your testing, attempting to reproduce this bug, on Athlon hardware
similar to what I use, right?

Having upgraded to FC4, I still see the same problems.


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