Red Hat Bugzilla – Bug 138942
double free or corruption: 0x082f7d50
Last modified: 2007-11-30 17:10:54 EST
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)
What's the version of your glibc ? I cannot reproduce this with vim-enhanced-6.3.030-3 and glibc-2.3.3-73
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 ...
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..
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.
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@redhat.com> Compiled by <bugzilla@redhat.com> 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]#
Assuming the swap file doesn't contain anything sensitive, could you attach it to this bug?
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?)
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?
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.
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.
The swap and strace log files above were generated using vim-enhanced-6.3.054-0.fc3.1
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?)
Still not reproducable (vim-6.3.086). Please reopen when you can provide a reproducable testcase
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.