vim using up 100% CPU, can't kill it












0















Every so often (about once a month), my vim starts eating resources like crazy, and I'm unable to kill it. Here's an example:



enter image description here



I ran:



kill 13799 


To no effect. I would like to know:



1) Could be vim going haywire due to something else? I use it to write code in and it's usually when the code is running that I get an issue.
2) If not, why would vim do this?
3) How can I kill it? Currently, I have to reboot every time.



Thanks )










share|improve this question























  • kill -9 $(pidof vim)

    – kenn
    Jan 9 at 13:37













  • It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have autoread enabled? Do you have lots of plugins installed? etc.

    – Dan
    Jan 9 at 13:41













  • Maybe clearing vim cache in ~/.viminfo fix it: stackoverflow.com/questions/2816719/…

    – kenn
    Jan 9 at 13:55













  • Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.

    – Neil
    Jan 9 at 13:57
















0















Every so often (about once a month), my vim starts eating resources like crazy, and I'm unable to kill it. Here's an example:



enter image description here



I ran:



kill 13799 


To no effect. I would like to know:



1) Could be vim going haywire due to something else? I use it to write code in and it's usually when the code is running that I get an issue.
2) If not, why would vim do this?
3) How can I kill it? Currently, I have to reboot every time.



Thanks )










share|improve this question























  • kill -9 $(pidof vim)

    – kenn
    Jan 9 at 13:37













  • It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have autoread enabled? Do you have lots of plugins installed? etc.

    – Dan
    Jan 9 at 13:41













  • Maybe clearing vim cache in ~/.viminfo fix it: stackoverflow.com/questions/2816719/…

    – kenn
    Jan 9 at 13:55













  • Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.

    – Neil
    Jan 9 at 13:57














0












0








0








Every so often (about once a month), my vim starts eating resources like crazy, and I'm unable to kill it. Here's an example:



enter image description here



I ran:



kill 13799 


To no effect. I would like to know:



1) Could be vim going haywire due to something else? I use it to write code in and it's usually when the code is running that I get an issue.
2) If not, why would vim do this?
3) How can I kill it? Currently, I have to reboot every time.



Thanks )










share|improve this question














Every so often (about once a month), my vim starts eating resources like crazy, and I'm unable to kill it. Here's an example:



enter image description here



I ran:



kill 13799 


To no effect. I would like to know:



1) Could be vim going haywire due to something else? I use it to write code in and it's usually when the code is running that I get an issue.
2) If not, why would vim do this?
3) How can I kill it? Currently, I have to reboot every time.



Thanks )







vim kill top






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 9 at 13:31









NeilNeil

1183




1183













  • kill -9 $(pidof vim)

    – kenn
    Jan 9 at 13:37













  • It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have autoread enabled? Do you have lots of plugins installed? etc.

    – Dan
    Jan 9 at 13:41













  • Maybe clearing vim cache in ~/.viminfo fix it: stackoverflow.com/questions/2816719/…

    – kenn
    Jan 9 at 13:55













  • Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.

    – Neil
    Jan 9 at 13:57



















  • kill -9 $(pidof vim)

    – kenn
    Jan 9 at 13:37













  • It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have autoread enabled? Do you have lots of plugins installed? etc.

    – Dan
    Jan 9 at 13:41













  • Maybe clearing vim cache in ~/.viminfo fix it: stackoverflow.com/questions/2816719/…

    – kenn
    Jan 9 at 13:55













  • Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.

    – Neil
    Jan 9 at 13:57

















kill -9 $(pidof vim)

– kenn
Jan 9 at 13:37







kill -9 $(pidof vim)

– kenn
Jan 9 at 13:37















It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have autoread enabled? Do you have lots of plugins installed? etc.

– Dan
Jan 9 at 13:41







It would be hard to figure out the reason, are you editing some very large files? Did you copy/paste some text by mistake while in command mode (This can run the commands which may need a while process)? When you run the code, is it modifying some larger files that you have open in vim while you have autoread enabled? Do you have lots of plugins installed? etc.

– Dan
Jan 9 at 13:41















Maybe clearing vim cache in ~/.viminfo fix it: stackoverflow.com/questions/2816719/…

– kenn
Jan 9 at 13:55







Maybe clearing vim cache in ~/.viminfo fix it: stackoverflow.com/questions/2816719/…

– kenn
Jan 9 at 13:55















Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.

– Neil
Jan 9 at 13:57





Thanks for the comments. I'll try clear cache and kill -9 next time. @Dan maybe plugins are the issue yea, I have quite a few.

– Neil
Jan 9 at 13:57










1 Answer
1






active

oldest

votes


















0














kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.



You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.



Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.



kill -9 13799


It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).



This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.






share|improve this answer
























  • Okay great that make sense. Thanks.

    – Neil
    Jan 13 at 14:16











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1108290%2fvim-using-up-100-cpu-cant-kill-it%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.



You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.



Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.



kill -9 13799


It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).



This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.






share|improve this answer
























  • Okay great that make sense. Thanks.

    – Neil
    Jan 13 at 14:16
















0














kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.



You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.



Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.



kill -9 13799


It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).



This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.






share|improve this answer
























  • Okay great that make sense. Thanks.

    – Neil
    Jan 13 at 14:16














0












0








0







kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.



You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.



Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.



kill -9 13799


It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).



This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.






share|improve this answer













kill is quite polite by default, it raises the SIGTERM signal. With this, the application is expected to see and handle the signal (eg quit) but that is completely up to the application to be able and willing.



You can see here that vim is "running" —that's what the R means— and that means it's likely too busy to intercept and process the signal. If it's been doing this a while, you may have stumbled on a bug.



Either which way, if you want to forcibly nuke it, you can use other signals. SIGKILL is a popular choice.



kill -9 13799


It cannot be ignored as it interrupts the current process (with some run-state exceptions, like zombie or other uninterruptible states).



This is an extremely high-level look at this. Take a look at man 7 signal to zoom in.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 11 at 9:46









OliOli

222k87562763




222k87562763













  • Okay great that make sense. Thanks.

    – Neil
    Jan 13 at 14:16



















  • Okay great that make sense. Thanks.

    – Neil
    Jan 13 at 14:16

















Okay great that make sense. Thanks.

– Neil
Jan 13 at 14:16





Okay great that make sense. Thanks.

– Neil
Jan 13 at 14:16


















draft saved

draft discarded




















































Thanks for contributing an answer to Ask Ubuntu!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1108290%2fvim-using-up-100-cpu-cant-kill-it%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

How to change which sound is reproduced for terminal bell?

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

Can I use Tabulator js library in my java Spring + Thymeleaf project?