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

Potential Memory Leak w/ function local variables #2877

Closed
PhilCCMG opened this issue Mar 24, 2020 · 11 comments
Closed

Potential Memory Leak w/ function local variables #2877

PhilCCMG opened this issue Mar 24, 2020 · 11 comments

Comments

@PhilCCMG
Copy link

Description

When writing functions (not procedures), storing local variables are potentially causing a memory leak as they do not appear to be deleted once the function returns a value.

Steps to Reproduce

  1. Write a function which is often called setting numerous variables, for example
function orderLore(i: item) :: item:
    set {_lore::*} to lore of {_i}
    set {_hasce} to false
    set {_enchants} to ""
    loop {_lore::*}:
        set {_b} to loop-value
        replace all "&a" and "&b" with "" in {_b}
        set {_b::*} to {_b} split at " "
        set {_b} to {_b::1}
        {_enchants::*} contains {_b}:
            {_enchants} is "":
                set {_enchants::*} to "%loop-value%"
            else:
                set {_enchants::*} to "%{_enchants}%", "%loop-value%"
        else if loop-value contains "Rarity: ":
            set {_rarity} to loop-value
        else:
            size of {_other::*} is 0:
                set {_other::*} to "%loop-value%"
            else:
                add "%loop-value%" to {_other::*}
    set {_lore::*} to {_enchants::*}, {_other::*}
    set {_i}'s lore to {_lore::*}
    return {_i}
  1. Run the function on a consistent basis every few seconds.
  2. After approximately 1-2 hours, the server will start to dramatically spike in RAM usage.

Expected Behavior

Local variables should be fully deleted from the RAM and the server should not keep tracking them.

Errors / Screenshots

Here is a screenshot of the Eclipse Memory Analyser taken during a lagspike.
image

Server Information

  • Server version/platform: 1.12.2 Paper
  • Skript version: Skript 2.4

Additional Context

Potentially similar to #2337, though it is marked as closed before 2.4 was released.

@JRoy
Copy link
Contributor

JRoy commented Mar 24, 2020

Can you reproduce this in 2.5-alpha2?

@PhilCCMG
Copy link
Author

I'll give it a shot - as stated it takes up to two hours to reproduce as it accumulates and only seems to start after a certain amount of time, but will try.

@PhilCCMG
Copy link
Author

Server isn't even booting; has this error about 50 times on 2.5-alpha2
https://hastebin.com/erehihudin.cs

@bensku
Copy link
Member

bensku commented Mar 24, 2020

Please try without addons, this should have been fixed before 2.4 was released.

@PhilCCMG
Copy link
Author

Hard to tell if it's directly continuing without addons but appears to be.

@PhilCCMG
Copy link
Author

From digging into a heapdump in a bit more detail, it seems to be setting a variable to something split, for instance:

set {_lore::*} to player's tool's lore
loop {_lore::*}:
    set {_lines::*} to loop-value split at " " # This seems to be causing the leak

@PhilCCMG
Copy link
Author

I'm mistaken.

The {_lore::*} variable from above was set 16 million times after 4 hours of uptime. I'd presume the local variable isn't being deleted when in list form.

@PhilCCMG
Copy link
Author

image
As an example, however, we see {_lore::*} is being stored 300,000 times in RAM which shouldn't be happening.

@ham1255
Copy link

ham1255 commented Jun 14, 2020

after doing testing with @Govindass quick solution is to delete local variable at the end of a code
like showing below.

delete {_receivers::*}

@Whimsyturtle
Copy link
Member

I'm not sure if this issue is the same as the issue that I reported in #2337, but it seems like #2337 is still an issue in Skript 2.5-alpha3.

@Whimsyturtle Whimsyturtle added the bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. label Jun 18, 2020
@Whimsyturtle
Copy link
Member

Closing in favor of #2337, to consolidate this issue.

@Whimsyturtle Whimsyturtle removed the bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. label Jul 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants