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

TempVars acquired but not released #1417

Closed
stephengold opened this issue Nov 9, 2020 · 9 comments
Closed

TempVars acquired but not released #1417

stephengold opened this issue Nov 9, 2020 · 9 comments
Labels

Comments

@stephengold
Copy link
Member

The NetBeans code inspector reports 12 instances in jme3-core where TempVars.get() is invoked and there's a codepath that does not result in the object being released. Here is a typical example:

If a path leading to a return statement (such as the one in line 759) is taken, then vars is never released. This constitutes a memory leak.

This is an easy fix for anyone with access to NetBeans. Please fix ALL instances reported by the inspector tool.

@pspeed42
Copy link
Contributor

pspeed42 commented Nov 9, 2020

The finally block will always be executed for anything inside the try. So I can't see how this could leak.

@tonihele
Copy link
Contributor

tonihele commented Nov 9, 2020

@pspeed42 is right. That tempvars thing is our own hint. I can take a look on the SDK side why it says so. That particular hint was the hardest to convert to the new module format, maybe I made a bug in the process :)

@pspeed42
Copy link
Contributor

pspeed42 commented Nov 9, 2020

Note that further down in the file, public float distanceToEdge(Vector3f point) { is a legitimate example because it doesn't use a try/finally block.

If the passed in point is null then it will throw an NPE after retrieving the temp vars and then never release it.

All temp vars usage should be following the try/finally pattern that the collideWithRay() method is actually doing correctly.

What's concerning is that Netbeans is flagging issues that aren't really there.

@stephengold
Copy link
Member Author

Paul is right. I put too much faith in the inspector.

@MeFisto94
Copy link
Member

Well, as @tonihele said, Netbeans itself wouldn't care about tempvars, that's something we put into the SDK specifically and it probably doesn't know about exception handling

@pspeed42
Copy link
Contributor

pspeed42 commented Nov 9, 2020

It would be nice if the tool could be fixed.

...but also note that we accidentally found a legitimate issue because I happened to scan down the file and do a "Paul code analysis". lol

@tonihele
Copy link
Contributor

tonihele commented Nov 9, 2020

We will try! We accidentally found two issues, in two projects. So in all I guess this was a success story!
jMonkeyEngine/sdk#291

@tonihele
Copy link
Contributor

@pspeed42 or someone, is there any reason why TempVars can't implement AutoCloseable? You could use these with try-with and all the code analyzers will warn about resource leaks...

@pspeed42
Copy link
Contributor

AutoCloseable is probably fine.... it's just unfortunate that we'd have to implement a 'close' method that language-wise doesn't make as much sense here.

It would be interesting to see if those code analyzers suffer from the same try/finally issue. I would hope not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants