-
Notifications
You must be signed in to change notification settings - Fork 79
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
phihat1, phihat2 and phihat3 are not correctly freed in some error cases resulting in memory leaks #547
Comments
Is this type 3 only? CPU or GPU? Etc. Can you make a concrete proposal? |
This is type3 CPU only. If we use std::vector instead of malloc/free the memory leak goes away without extra effort. Othwewise we need to define an error handler in cpu finufft setpts for type 3 that make sure to free all the memory before returning. I'd rather do the de/macroize as it is less error prone. This memory leak occurs only in case of errors so it is not super critical to fix as I expect the user to terminate the program if the nufft fails but we should fix it now that we spotted it. |
great, make a std::vector PR just for those and we'll bring to 2.3.1.
…On Thu, Sep 5, 2024 at 12:33 PM Marco Barbone ***@***.***> wrote:
This is type3 CPU only. If we use std::vector instead of malloc/free the
memory leak goes away without extra effort. Othwewise we need to define an
error handler in cpu finufft setpts for type 3 that make sure to free all
the memory before returning. I'd rather do the de/macroize as it is less
error prone.
This memory leak occurs only in case of errors so it is not super critical
to fix as I expect the user to terminate the program if the nufft fails but
we should fix it now that we spotted it.
—
Reply to this email directly, view it on GitHub
<#547 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACNZRSXKB2VHGK4XCJSTBVDZVCBUFAVCNFSM6AAAAABNVDDVNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZSGE3TQMBRGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
*-------------------------------------------------------------------~^`^~._.~'
|\ Alex Barnett Center for Computational Mathematics, Flatiron Institute
| \ http://users.flatironinstitute.org/~ahb 646-876-5942
|
Ok, we wait until de-macro-ize which will use std::vector. |
This should be fixed now, correct? |
Indeed. |
This problem will once we de macroize and we use stl containers instead of malloc/free.
The text was updated successfully, but these errors were encountered: