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
Comments
The finally block will always be executed for anything inside the try. So I can't see how this could leak. |
@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 :) |
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. |
Paul is right. I put too much faith in the inspector. |
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 |
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 |
We will try! We accidentally found two issues, in two projects. So in all I guess this was a success story! |
@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... |
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. |
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:jmonkeyengine/jme3-core/src/main/java/com/jme3/bounding/BoundingBox.java
Line 731 in c7ff806
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.
The text was updated successfully, but these errors were encountered: