Sublime Forum

Memory Leak - latest dev build (3156 Linux)

#1

Running Ubuntu 17.04 64bit and have Sublime Text 3 build 3156.
Was having memory leak problems (started at 75Mb odd and would grow to >600Mb over time).
Just did a revert according to instructions.
In the last few hours, memory usage has grown from 75Mb to over 260Mb and continues to grow at around 3-4Mb per minute (very rough estimate) whilst it sits idle (no editing being performed).
Package Control installed (v3.3.0) but no packages.
Have 4 very small files (7.5k, 232bytes, 232bytes, 867bytes) open - no editing whilst memory leak grows.
Means that I must exit Sublime Text regularly and restart.
Can anything be done about this?

1 Like

#2

Do you have a project or folder loaded?

0 Likes

#3

No, no folder or project (don’t use these currently).
After leaving it open for 2 days, the memory usage went to 1.7Gb.

0 Likes

#4

Do you see it with a clean install (no Package Control)?

Can you provide the contents of your console from a clean start until you see the usage grow above 1GB?

260MB of memory usage is typical once various syntax definitions are loaded into memory.

Usually memory leaks like these are due to misbehaving packages. Since all you have installed is Package Control, perhaps this is causing an issue on your machine?

0 Likes

#5

What do you mean by the contents of the console? What or where is this?
BTW I have the same build running on Win10 with package control and many packages installed and it has been stable at 95.6Mb for many many days.

0 Likes

#6

Press ctrl+` to open the console.

0 Likes

#7

I am getting the same, for what it’s worth, on Build 3156, Linux Mint.

I have package control and a few Dlang specific packages, and I typically do have a project open, but if I restart and load a project (not a Dlang project, just LaTex) then it will start at around 100MiB~ and its memory usage will remain stable. As soon as I hit F7 and build the PDF for my document, the memory usage will (not immediately with the new build, but after the console output has stopped) slowly begin to climb by about 200KiB or so.

I can watch it go from 106.1MiB, to 106.3MiB, to 106.5MiB as I’m typing this. Subsequent builds seem to also increase the speed at which this memory usage increases.

0 Likes

#8

There are various places in which we use custom allocators that could result in patterns like this. I would be more concerned about 300MB+ of memory usage and having it continue to grow over time.

0 Likes

#9

Sorry, I was interrupted earlier while writing the last post.

What I meant to say was that I quite often find sublime has grown to use over 1GiB of memory after a couple of hours. Sometimes haven’t not used it for quite a while after using it to build a PDF using latexmk.

This is definitely new in one of the latest builds, but the memory grows to the extreme which is why I wanted to see if this was just me or if somebody had found a memory leak.

0 Likes

#10

If you have third-party packages installed, it gets a lot harder to pin down what may be going on.

0 Likes

#11

Packages can do that easily. I found myself with such problem, and after a extensive search I found a package doing it. You can see the detailed report here: add_regions causes Sublime Text to hang for ever after eating 1.81GB of RAM

0 Likes

#12

OK - I have been away but recently returned to do some tests on the Sublime Text Build 3156 memory leak issue.
Still happening!
I completely deleted everything in ~/.config/sublime-text-3 except for the licence key file (just so I did not have to re-enter that again). Thus, a vanilla install (according to the instructions I read).

Started ST and opened the console. Copied it to a file and then observed memory usage (using Task Manager) whilst DOING NOTHING at all in ST, apart from occasionally entering the results of the memory usage, at the bottom of the file, as can be seen below.

I did this on an Ubuntu 17.04 installed on PC hardware directly, as well as on Ubuntu 17.04 installed inside a VirtualBox (latest build - just recently downloaded and installed/updated) on another completely different PC. First PC has 8Gb real memory and second PC has 32Gb real memory.

Results output below. Note that the second PC memory leak appears to have slowed (but not totally certain - haven’t done any stats on it), whereas the first continues unabated.

Note that I was requested to get a copy of the console after the memory increased. I opened and closed the console a couple of times but it DID NOT CHANGE from the time of startup. Most likely because I was not doing any editing at all, only a minimal amount of typing (but, once again, I have no idea why not).

Here are the outputs:

Sublime Text Memory Leak - January 2018 - on AZ5771

Startup 20180128t1141

All files and folders in /home/ts/.config/sublime-text-3/ deleted apart from Local and Lib - only leaving the licence file in Local

Console

startup, version: 3156 linux x64 channel: dev
executable: /opt/sublime_text/sublime_text
working dir: /
packages path: /home/ts/.config/sublime-text-3/Packages
state path: /home/ts/.config/sublime-text-3/Local
zip path: /opt/sublime_text/Packages
zip path: /home/ts/.config/sublime-text-3/Installed Packages
ignored_packages: [“Vintage”]
generating syntax summary
generating meta info summary
pre session restore time: 1.47804
startup time: 1.65607
first paint time: 1.70945
reloading plugin Default.arithmetic
reloading plugin Default.auto_indent_tag
reloading plugin Default.block
reloading plugin Default.colors
reloading plugin Default.comment
reloading plugin Default.convert_color_scheme
reloading plugin Default.convert_syntax
reloading plugin Default.copy_path
reloading plugin Default.delete_word
reloading plugin Default.detect_indentation
reloading plugin Default.duplicate_line
reloading plugin Default.echo
reloading plugin Default.exec
reloading plugin Default.fold
reloading plugin Default.font
reloading plugin Default.goto_line
reloading plugin Default.history_list
reloading plugin Default.indentation
reloading plugin Default.install_package_control
reloading plugin Default.kill_ring
reloading plugin Default.mark
reloading plugin Default.new_templates
reloading plugin Default.open_context_url
reloading plugin Default.open_in_browser
reloading plugin Default.pane
reloading plugin Default.paragraph
reloading plugin Default.paste_from_history
reloading plugin Default.profile
reloading plugin Default.quick_panel
reloading plugin Default.rename
reloading plugin Default.run_syntax_tests
reloading plugin Default.save_on_focus_lost
reloading plugin Default.scroll
reloading plugin Default.set_unsaved_view_name
reloading plugin Default.settings
reloading plugin Default.show_scope_name
reloading plugin Default.side_bar
reloading plugin Default.sort
reloading plugin Default.swap_line
reloading plugin Default.switch_file
reloading plugin Default.symbol
reloading plugin Default.transform
reloading plugin Default.transpose
reloading plugin Default.trim_trailing_white_space
reloading plugin Default.ui
reloading plugin CSS.css_completions
reloading plugin Diff.diff
reloading plugin HTML.encode_html_entities
reloading plugin HTML.html_completions
reloading plugin ShellScript.ShellScript
plugins loaded

Memory Stats

| DateTime | VSZ (Mb) | RSS (Mb) |
| 20180128t1141 | 905.9 | 65.4 |
| 20180128t1151 | 1300.0 | 81.1 |
| 20180128t1305 | 1300.0 | 120.5 |
| 20180128t1549 | 1400.0 | 202.3 |
| 20180128t2045 | 1500.0 | 358.5 |
| 20180129t0808 | 1900.0 | 717.9 |
| 20180129t0952 | 1900.0 | 767.8 |

Sublime Text Memory Leak - Ubuntu VirtualBox on dairbinup

Start on 20180128t1346

Console

startup, version: 3156 linux x64 channel: dev
executable: /mnt/d/opt/sublime_text/sublime_text
working dir: /
packages path: /home/ts/.config/sublime-text-3/Packages
state path: /home/ts/.config/sublime-text-3/Local
zip path: /mnt/d/opt/sublime_text/Packages
zip path: /home/ts/.config/sublime-text-3/Installed Packages
ignored_packages: [“Vintage”]
generating syntax summary
generating meta info summary
pre session restore time: 9.35553
startup time: 10.222
first paint time: 10.582
reloading plugin Default.arithmetic
reloading plugin Default.auto_indent_tag
reloading plugin Default.block
reloading plugin Default.colors
reloading plugin Default.comment
reloading plugin Default.convert_color_scheme
reloading plugin Default.convert_syntax
reloading plugin Default.copy_path
reloading plugin Default.delete_word
reloading plugin Default.detect_indentation
reloading plugin Default.duplicate_line
reloading plugin Default.echo
reloading plugin Default.exec
reloading plugin Default.fold
reloading plugin Default.font
reloading plugin Default.goto_line
reloading plugin Default.history_list
reloading plugin Default.indentation
reloading plugin Default.install_package_control
reloading plugin Default.kill_ring
reloading plugin Default.mark
reloading plugin Default.new_templates
reloading plugin Default.open_context_url
reloading plugin Default.open_in_browser
reloading plugin Default.pane
reloading plugin Default.paragraph
reloading plugin Default.paste_from_history
reloading plugin Default.profile
reloading plugin Default.quick_panel
reloading plugin Default.rename
reloading plugin Default.run_syntax_tests
reloading plugin Default.save_on_focus_lost
reloading plugin Default.scroll
reloading plugin Default.set_unsaved_view_name
reloading plugin Default.settings
reloading plugin Default.show_scope_name
reloading plugin Default.side_bar
reloading plugin Default.sort
reloading plugin Default.swap_line
reloading plugin Default.switch_file
reloading plugin Default.symbol
reloading plugin Default.transform
reloading plugin Default.transpose
reloading plugin Default.trim_trailing_white_space
reloading plugin Default.ui
reloading plugin CSS.css_completions
reloading plugin Diff.diff
reloading plugin HTML.encode_html_entities
reloading plugin HTML.html_completions
reloading plugin ShellScript.ShellScript
plugins loaded

Memory Stats

| DateTime | VSZ (Mb) | RSS (Mb) |
| 20180128t1346 | 892 | 111 |
| 20180128t1348 | 1100 | 145.4 |
| 20180128t1433 | 1200 | 154.6 |
| 20180128t2118 | 1400 | 371.8 |
| 20180129t0947 | 1400 | 377.7 |

So, looking at any hints about what to do next - or even getting this fixed (since it ultimately makes ST far far less useful than what I purchased).

1 Like

#13

I’m also seeing this, same version, under Windows.

I have a dump file I can send.

Edit: On second thought, I read the comment about having a project folder loaded. Yes, I did. I use SFTP Net Drive and opened root on my target Linux machine. I changed to the folder I really use and no more endless memory allocation.

0 Likes

#14

I can’t believe it took me this long to realize that I was doing that. I switched from ExpanDrive to SFTP Net Drive a couple of weeks ago and my machine seemed to be constantly running after that. I only noticed Sublime’s memory usage a couple of days ago.

I’m guessing that the memory usage is from a process that looks for all files in a “project”? I can see why it wasn’t a problem under ExpanDrive because Expandrive is horrible and probably stopped connecting. But under something “robust” like SFTP Net Drive or even locally, maybe Sublime should have a limit to the number of files it looks for in a project which can be overridden but if reached, will display something. The directory that I should have been using for my project has 32k files and the amount of memory Sublime is taking up is ridiculously small compared to what it was doing before. Maybe a default limit of 64k worth of files?

0 Likes

#15

May it be possible for ST3 to suffer from a python 3.3 bug, which causes some objects whose classes define a destructore not to be deleted by the garbage collector? I’ve recently read about such thing somewhere in the asyncio library.

asyncio/future.py

    # On Python 3.3 and older, objects with a destructor part of a reference
    # cycle are never destroyed. It's not more the case on Python 3.4 thanks
    # to the PEP 442. 
1 Like

#16

This is still happening for me, too, on Linux after having removed all of my packages. Not really sure what’s going on.

0 Likes

#17

You are seeing constant increasing memory usage? Have you opened a huge folder, such as your home dir, or root of the filesystem?

Sublime Text keeps a catalog of every file and folder that has been opened. This allows Goto File to work instantaneously. If you have millions of files, I could see how memory usage would increase as each folder was added to the catalog. If you had a slow filesystem, such as sshfs or nfs, you may notice a gradual increase since the performance of scanning for files/folders would be slower.

0 Likes

#18

Hi Will,

Yeah it seems that it just grows continuously at a constant rate, but that if I build the latex files it can sometimes increase the rate at which is builds, so maybe it is the cataloging of my particular project?
My file system is Ext4, and I have about 4,835 in the directory, but many are PDFs. The main files are just .tex and the related files.

Thanks.

0 Likes

#19

I know this is quite useless, but after the latest update, this doesn’t seem to be a problem for me anymore. I don’t know something else updated, as I had reinstalled my packages since removing them. But the memory usage has returned to how I remember it. It doesn’t climb dramatically after building LaTeX projects.

0 Likes

#20

There was a fix related to a memory bug (the one in regards to syntax contexts that have a regex backref in a pop pattern). Perhaps it manifested itself differently on your machine with the syntaxes you use.

0 Likes