Sublime Text 3 (Build 3211) memory leak and high cpu usage

[utopiarebels]

Hi, I am running latest sublime text 3 at this time (Build 3211) on ubuntu 18.04, and it is consuming a lot of memory and cpu. It happened a month ago and I have tried to fix it for a while. So I then try to use minimal setup to debug it:

1. The test project I opened only contains dozens of python scripts and some c files, in total 1.1MB in size
2. Removed all packages/plugins and revert to clean states (remove the ~/.config/sublime-text-3/ directory)
3. Already tried to remove/purge it and reinstall multiple times

Even after doing all above, the cpu usage rase up to 100% immediately on 2 cores (my machine has 8 cores) the moment I opened my project and never came down, just like how it was when it happened initially. Moreover, the memory usage increases forever for that 1.1MB project, and it would slowly fill up the entire memory and freeze my machine if I dont kill it early enough, and the only solution now is a cold reboot.

Can some one tell me how I can fix it (or debug it)? I could live with some workaround/hacks if there is. Thanks!

[bschaaf]

Could you try disabling file indexing with "index_files": false.

[utopiarebels]

Thanks for your reply!

Sorry that I forgot to mention that disabling indexing is one of the first things I tried to solve the problem, and I just double checked that it still doesn’t work for me. Do you have any other ideas?

[bschaaf]

Just to confirm: This doesn’t happen for other projects and still happens with a completely fresh state and indexing disabled? Is there any way you could share this project? Which process is the one eating your cpu/memory (sublime_text or plugin_host)?

[utopiarebels]

I couldn’t say it would happen to all projects, cuz if I just open few random small files then it get handled quickly and stayed in happy state. But I can reproduce it easily with anything that related what I’m working on currently (and yes it happens with a completely fresh state and indexing disabled).

I just found a good project example that’s both small in size and simple in structure, so that you may have a look. It’s a public repo on github for yocto called poky, and I only open up the directory meta-poky (less than 200KB in size).The repo can be found at https://github.com/mendersoftware/poky/tree/master/meta-poky

If run tree for this directory:

$ tree meta-poky/
meta-poky/
├── classes
│   └── poky-sanity.bbclass
├── conf
│   ├── bblayers.conf.sample
│   ├── conf-notes.txt
│   ├── distro
│   │   ├── include
│   │   │   ├── poky-distro-alt-test-config.inc
│   │   │   ├── poky-floating-revisions.inc
│   │   │   └── poky-world-exclude.inc
│   │   ├── poky-altcfg.conf
│   │   ├── poky-bleeding.conf
│   │   ├── poky.conf
│   │   └── poky-tiny.conf
│   ├── layer.conf
│   ├── local.conf.sample
│   ├── local.conf.sample.extended
│   └── site.conf.sample
├── README.poky
└── recipes-core
    ├── busybox
    │   ├── busybox
    │   │   └── poky-tiny
    │   │       └── defconfig
    │   └── busybox_%.bbappend
    ├── psplash
    │   ├── files
    │   │   └── psplash-poky-img.h
    │   └── psplash_git.bbappend
    └── tiny-init
        ├── files
        │   ├── init
        │   └── rc.local.sample
        └── tiny-init.bb

12 directories, 22 files

This is what it looks like in htop with only this project (meta-poky) opened, and the VIRT increases forever while it is opened. And based on that I assume it’s sublime-text itself eating cpu/memory

[bschaaf]

Another question: Is Sublime Text frozen when this happens or does it stay responsive?

[utopiarebels]

It stays responsive during memory increase, but if the memory usage hits the limit of the machine then it would freeze the entire machine with no doubt.

[bschaaf]

Shot in the dark, but could you try "show_git_status": false? Are you using a network drive for these files?

[utopiarebels]

Surprisingly that does solve the issue! I’ve tested with multiple other directories with tons of files and cpu/memory never reach to the top anymore

And also I tried revert the change (remove the line "show_git_status": false in my settings) and saw the memory leak again, which confirms that this indeed is the cause of it. It’s sad that I lose the nice interface to sublime merge, but I’m glad sublime is back to a usable state!

Thank you very much, I’m so appreciated!

[utopiarebels]

probably also worth noting that it looks all good after adding back all my plugins and enabling indexing

[bschaaf]

If you make htop display thread names (https://askubuntu.com/questions/987957/how-to-see-thread-name-in-htop) and confirm that the git_thread is the one eating all the CPU?

[utopiarebels]

yup, a monster called git_thread is right at the top:

[bschaaf]

Could you provide a perf sample using perf record -g -p $(pidof sublime_text)? Alternatively a couple tracebacks using gdb would also help if that’s easier.