-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
memory leak unexplained #4674
Comments
I notice that you don't actually shut down the JS environment at all; are you just killing the process to end it and then watching valgrind's output? If you don't gracefully terminate the runtime then we don't get a chance to tear down the garbage collector etc. |
You are perfectly right ! When the runtime is gracefully stopped, all the memory is restored and Valgrind complains no more about leaked memory. I don't know if such a small "leak" (does look more of local variables that don't get cleaned) presents any risks. For the current time I'm just making little tests so I will not have the opportunity to dig the subject further. |
I don't think that it is explained: why is the JS engine "eating" memory when doing nearly nothing ? Yes there isn't a "leak" (perhaps because you use a memory pool, and by stopping the engine we free all the pool), but, on use, the engine seems to, at least, "lost" some memory. But in the end, you are more competent than I am, so if you think that the topic is close, so be it[1]. [1] to avoid any misunderstanding, I mean it when I say that you know what you're doing; the english is not my native language, so please excuse me, if I'm offensing. |
I think I'm right in saying that any script provided to the RunScript is cached for the duration of the Context - this is intentional so that when a function in one script calls one in another it's still there for. This is likely the cause of your increase in memory usage you're cache'ing many many copies of your script with that loop - it's all released when you close down the context. This gradual increase would not happen if you ran one script containing the loop or if you called a function repeatedly with JsCallFunction rather than Parsing a new script over and over. |
It seems logicial (even though it seems there is no new symbol "callable/reachable" added by my script: |
I found an example of reason to keep the code: the debug interface allows to reference precisely a script and line column (see JsDiagSetBreakpoint), so the code must be kept symbol "callable/reachable" or not. Now I can have my mind at ease :-) |
Hi !
I'm going further (I'm near to have a bridge Qt-ChakraCore; I will soon add property management through Proxy).
the problem
For now I was doing some tests about memory management (I didn't quite get all about memory) and I saw that there is a slow and steady memory increase when I'm repeatedly calling JsRun, asking it to run this instruction:
having in my function nothing but this:
so having nothing.
I altered my previous code #4669, as you can see below.
As the increase is done slighty over the time I made a video as a proof: memory_consumption.mp4.gz
I used valgrind for tracking the origin, and found that there "may be" some memory lost in several places (see the end of the log file: valgrind_output.txt)
And last but not least, I used in my test a call to the garbage collector, but it changed nothing.
my question
Is there something that I missed about memory management ?
hardware/software
code used for the test
The text was updated successfully, but these errors were encountered: