-
Notifications
You must be signed in to change notification settings - Fork 0
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
Fix a couple memory leaks #263
Conversation
@@ -342,9 +347,11 @@ mkAPI dlib = flip runReaderT dlib $ do | |||
} | |||
len <- fromIntegral <$> peek lenPtr | |||
cstr <- peek strPtr | |||
BS.packCStringLen (cstr, len) | |||
result <- BS.packCStringLen (cstr, len) | |||
Foreign.free cstr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the spot here. I think I assumed that packCStringLen
just wraps the pointer, but upon checking it copies the memory. I wonder if it would be worth passing this pointer tot he parse function and freeing after to avoid this copy? Not sure how big the returned data can be.... perhaps something to investigate later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be worth it if we see performance issues related to this in a profile, but the advantage of this approach is that the native memory that is allocated is all isolated to this particular component, and all memory that gets used moving forward is just regular haskell heap memory. So I don't think we should prematurely optimize here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, provided the tests pass with latest K
c4adbb9
to
b35b48d
Compare
This is a cherry-pick from #263 that we could merge much faster without investigating LLVM backend bindings. Co-authored-by: Dwight Guth <dwight.guth@runtimeverification.com>
Blocked on #264
We were never taking any rewrite steps, so the garbage collector was never getting called. We also forgot to call kllvm_init, which meant that some of the memory that ought to have been allocated on the garbage collected heap in the llvm backend was instead being allocated in the wrong place.
Finally, we forgot to call
free
on thechar*
returned fromkore_simplify
.