Closed ebenoist closed 3 years ago
+1, this bit me the other day.
Pull Requests welcome. I'm not sure what the safest way to define a finalizer on an ivar within a plain class.
@postmodern I have some spike code together, I think the only "gotcha" is if you define the finalizer proc within the instance of the class (then the instance itself is never freed). Moving this to a singleton function should alleviate that issue. I'll get something a little cleaner and tested together in the next few days.
I think I've seen people put the proc into a class var or constant?
I think that would work as well.
@ebenoist so what I want to know is, how do you (or Ruby) prevent the finalizer from kicking off when you explicitly close the dictionary and destroy the pointer?
@postmodern I've been struggling with the same problem actually. I'm not sure yet.
I may have fixed another memory leak in Dictionary#stem
and Dictionary#suggest
where Hunspell_free_list
wasn't being called on the char **
returned by Hunspell_stem
and Hunspell_suggest
. ab0c6a36f7d5078f138bb5c4a211920ab6e45b2a
As for this issue with closing the dictionary pointer, maybe we could use FFI::AutoPointer?
See the auto_pointer branch and 530c548a12d7c4bed300faed18275523e3b6f121.
Merged into master and released 0.6.1. If there's still memory leaks detected, re-open this issue with fresh analysis.
There is a memory leak, which I am sure you aware of, when a new Dictionary object is created without being closed. I have some spike code that uses a finalizer to prevent this easy mistake.
I would want to clean it up, test it, and do a performance regression before putting up a PR, but wanted to see if you'd be interested in making this kind of enhancement first.