Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix slow memory leak caused by not clearing cache #5965

Merged
merged 1 commit into from
Jan 8, 2021
Merged

Conversation

kevin-brown
Copy link
Member

This pull request includes a

  • Bug fix
  • New feature
  • Translation

The following changes were made

  • Fixed memory leak caused by element reference not being removed from the cache

If this is related to an existing ticket, include a link to it as well.
Fixes #5912

There was a very slow memory leak that can occur if you were creating
and destroying many Select2 elements on a single page. This was caused
by the internal Select2 cache not being cleared for the container
element, causing a reference to it to be left in memory even after
the Select2 element was destroyed.

The memory was put in place to make it easier to destroy a Select2
element after it is initialized, specifically when the user clicks
off of the Select2 element. Because some pages run with multiple
versions of Select2 and jQuery at the same time, we specifically
cache a local copy of the jQuery element to allow it to be
deconflicted at the time of the call. This cached locally copy was
not being properly cleared when Select2 was being destroyed though,
which had the (very small) potential to cause a memory leak over time.
@kevin-brown kevin-brown added the 4.x label Jan 8, 2021
@kevin-brown kevin-brown added this to the 4.1.0 milestone Jan 8, 2021
@kevin-brown kevin-brown merged commit 0de98d9 into develop Jan 8, 2021
@kevin-brown kevin-brown deleted the GH-5912 branch January 8, 2021 02:59
anttikuuskoski pushed a commit to anttikuuskoski/select2 that referenced this pull request Mar 29, 2022
There was a very slow memory leak that can occur if you were creating
and destroying many Select2 elements on a single page. This was caused
by the internal Select2 cache not being cleared for the container
element, causing a reference to it to be left in memory even after
the Select2 element was destroyed.

The memory was put in place to make it easier to destroy a Select2
element after it is initialized, specifically when the user clicks
off of the Select2 element. Because some pages run with multiple
versions of Select2 and jQuery at the same time, we specifically
cache a local copy of the jQuery element to allow it to be
deconflicted at the time of the call. This cached locally copy was
not being properly cleared when Select2 was being destroyed though,
which had the (very small) potential to cause a memory leak over time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Internal cache not cleared properly after destroying select2
1 participant