Bug 100771 - VIM runs away
Summary: VIM runs away
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vim   
(Show other bugs)
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: David Lawrence
URL: redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2003-07-25 06:49 UTC by Shaun Murphy
Modified: 2007-04-18 16:56 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-21 14:26:48 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Shaun Murphy 2003-07-25 06:49:39 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 

Description of problem:
This problem has been entered here before but none of the really explain the 
exact problem.

Problem: when installing vim-enhanced it creates a alias that profile runs and 
creates alias vi='vim'.  As you can see if you where to run vi it would in turn 
start vim.  This is great except when you loose your remote connection to the 
server or it receives a HANGUP or xterm gets closed when vim's runnign, etc.  
Basically anytime it's tty is lost.  If you where to run the actuall command 
vim this prolblem doesnt exist.  I beleive the reason for this is because maybe 
vim is detecting how it was started and is searching for it's process to kill?  
i dont know for sure.  all i know is the alias is whats causing this problem.  
VIM is not killing it self properly and in turn it consumes 99% CPU until it is 
killed.  This problem has been around for way too long now and is a big problem 
for my type of business (web hosting) as you can imagin many clients log in and 
use vi and alot of them may loose their session.

Here's a strace of what happens when the session is lost.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.log into the box via ssh
2.install vim-enhanced
3.ensure the alias vi='vim' exits
4.start vi by typeing vi bugtest
5.close the ssh session with out quiting vi
6.log back in, run top and wala, vim is going crazy

Additional info:

Comment 1 Shaun Murphy 2003-07-25 06:51:18 UTC
Bugzilla wont allow me to past the strace, looks like a bug in bugzilla.

Comment 2 Karsten Hopp 2003-07-31 11:24:08 UTC
I couldn't reproduce this with a current vim, can you please test if the  
vim*7.x* packages from http://people.redhat.com/karsten/ fix this problem ? 

Comment 3 Shaun Murphy 2003-07-31 19:19:06 UTC
Yes, those 7.x packages fixed the problem.  Note that the current vim packages 
i had installed before installing these were the latest from errata.  Can we 
get these released on errata asap if possible.

Comment 4 John Hardin 2003-09-25 17:52:34 UTC
Isn't this a duplicate of bug 83700 ?

Comment 5 Shaun Murphy 2003-09-25 18:33:19 UTC
It's probably the same issue but i give more information about how to duplicate 
the problem.  This issue still has no been resolved.  Whats the deal?  The rpms 
you had me install above seamed to solve the problem but i need a errata update.

Comment 6 John Hardin 2003-09-25 20:26:14 UTC
This does not correct the problem in vim. /bin/vi is a simple version of vim,
probably not compiled with the +python support that causes the runaway process.
If you run vim directly and kill the window, it still goes runaway.

If you don't mind losing the features of vim (like multiwindow editing) killing
the "vi" alias might be a useful workaround.

Comment 7 Shaun Murphy 2003-09-25 22:24:42 UTC
The software should not be running away like this and causing 99% cpu load.  
This is a bug and should be fixed.

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