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

Fix a couple memory leaks #263

Merged
merged 8 commits into from
Aug 24, 2023
Merged

Fix a couple memory leaks #263

merged 8 commits into from
Aug 24, 2023

Conversation

dwightguth
Copy link
Collaborator

@dwightguth dwightguth commented Aug 11, 2023

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 the char* returned from kore_simplify.

@@ -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
Copy link
Contributor

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

Copy link
Collaborator Author

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.

Copy link
Contributor

@goodlyrottenapple goodlyrottenapple left a 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

@dwightguth dwightguth marked this pull request as ready for review August 17, 2023 17:24
@goodlyrottenapple goodlyrottenapple dismissed their stale review August 21, 2023 08:26

Tests do not pass

rv-jenkins pushed a commit that referenced this pull request Aug 22, 2023
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants