🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
AS 2.0a: No decrement for ref count to handle sent to application function
Author
Possible bug in AS 2.0a. I have a registered object. Refcount starts from 1 in constructor, class has proper AddRef/Release behaviors. All the refcount thingy works fine except for one case. When I send the handle to an application (not scripted!) the refcount is increased but never decreased so I end up with memory leaks as the object destructor is never reached. At least this is what I can figure out watching the breakpoints. Anyway the refcount is 1 (instead of zero) in the end.
Here is a quick example:
{
MyObj obj; // Refcount is 1 in constructor.
AppFuncCall(@obj); // Refcount ++ at enter, never -- at exit.
// Refcount is 2 at exit.
// Ref count is decreased when exiting the block.
}
// Refcount still 1 and object never released.
Please, if it is possible, put a test application in the feature_test for handles to application functions. It seems that there are lots of cases of handle use that are not tested there. Anyway great job until now, everything else seems to work fine after the 2.0a patch.
Thanks
Licu
The test_objhandle2.cpp covers this case.
AngelScript is correct in this case, as it is the responsibility of the application function to release the object handle. The reference is increased when the object handle is copied to the argument, at which point the application function is the owner of the handle and should either store it or release it.
Also when returning an object handle to the script engine the application is responsible for increasing the reference. The same for constructors, that should return with a reference already counted.
I intend to introduce a way of telling the library to automatically handle these addref/release calls. This would be especially useful when passing handles to application functions that expect a simple pointer. What I'm thinking right now is to add a token in the application function declaration, e.g. "obj@+ func(obj@+)". The extra + sign would then mean that the library will automatically make the necessary call to addref or release.
Until that is implemented, I'm afraid you'll have to either alter the implementation of your application function, or if that is not possible write a wrapper function that releases the object handle.
AngelScript is correct in this case, as it is the responsibility of the application function to release the object handle. The reference is increased when the object handle is copied to the argument, at which point the application function is the owner of the handle and should either store it or release it.
Also when returning an object handle to the script engine the application is responsible for increasing the reference. The same for constructors, that should return with a reference already counted.
I intend to introduce a way of telling the library to automatically handle these addref/release calls. This would be especially useful when passing handles to application functions that expect a simple pointer. What I'm thinking right now is to add a token in the application function declaration, e.g. "obj@+ func(obj@+)". The extra + sign would then mean that the library will automatically make the necessary call to addref or release.
Until that is implemented, I'm afraid you'll have to either alter the implementation of your application function, or if that is not possible write a wrapper function that releases the object handle.
Author
Quote: Original post by WitchLord
The test_objhandle2.cpp covers this case.
AngelScript is correct in this case, as it is the responsibility of the application function to release the object handle. The reference is increased when the object handle is copied to the argument, at which point the application function is the owner of the handle and should either store it or release it.
Yes you are right, sorry about that.
Anyway my opinion is that all this must be automatically done by the scripting engine since you can deal with functions that you don't have access to their code and also a wrapper can slow things. Another solution would be the syntax you've indicated. But I think that the default behavior should be the one in which the scripting engine takes care of handle and some additional operators should indicate that the function is responsable for it.
I thought about this a lot before deciding who should be responsible for cleaning up the arguments. I decided to go with the current way because it is easier to work around than the other case. E.g. if the library by default cleaned up the arguments, and the application wanted to register a method that also cleaned up the arguments, then a wrapper function would have to be written that adds an extra reference before calling the true application function.
The same goes for returning handles. If the library by default increases the reference when an application function returns a handle, then it wouldn't be possible to return a handle for which the application doesn't want to keep the reference, since the application would then have to somehow return the object handle with a reference count of 0.
The same goes for returning handles. If the library by default increases the reference when an application function returns a handle, then it wouldn't be possible to return a handle for which the application doesn't want to keep the reference, since the application would then have to somehow return the object handle with a reference count of 0.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
