I've just finished the first round of memory cleanups to NCO.
As we all know, NCO has always had small memory leaks.
Small leaks per se would not bother me except they tend to obscure
the serious bugs.
So for the last six months or so I've been trying to plug leaks.
I'm happy to report that ncpdq is now completely leak-free.
valgrind verifies this with, e.g.,
In the course of plugging ncpdq (the newest, and hence cleanest,
operator), I tried to better modularize the memory management.
You will see two blocks of code at the bottom of ncpdq.c:
The first block cleans up ncpdq-specific allocations.
The second block cleans up NCO-generic allocations.
This second block should be portable with minor modifications
to all the other operators.
Basically, the new policy is that all dynamic memory must be
free'd before exit, and the first block (i.e., the operator-specific
block of code) is the appropriate place to free things.
Please adopt this convention in any future code modifications.
I've begun leak-proofing ncap (hopeless, for now), ncwa (scary),
and ncra (looks fairly straightforward).
The clean-up requires cleanly separating system memory from process
memory (basically done), and re-writing some old core code (e.g.,
list-handling, file-handling, limits).
Cleaning up this core code requires changes to all the operators.
I try to keep the regression test working at every commit.
If you notice any failures, please let me know!
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FYI I just committed a second round of memory cleanups.
Now ncpdq and ncbo appear faultless.
Still working on ncra and then will try ncwa.
Latest changes include re-vamping of lmt structure code.
Changes to API from this are described in ChangeLog.
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I've just finished the first round of memory cleanups to NCO.
As we all know, NCO has always had small memory leaks.
Small leaks per se would not bother me except they tend to obscure
the serious bugs.
So for the last six months or so I've been trying to plug leaks.
I'm happy to report that ncpdq is now completely leak-free.
valgrind verifies this with, e.g.,
valgrind --leak-check=yes --show-reachable=yes --suppressions=${HOME}/c++/valgrind.txt ncpdq -O -D 3 -a lat,lev,lon -v three_dmn_var ~/nco/data/in.nc ~/foo.nc > ~/foo 2>&1
In the course of plugging ncpdq (the newest, and hence cleanest,
operator), I tried to better modularize the memory management.
You will see two blocks of code at the bottom of ncpdq.c:
The first block cleans up ncpdq-specific allocations.
The second block cleans up NCO-generic allocations.
This second block should be portable with minor modifications
to all the other operators.
Basically, the new policy is that all dynamic memory must be
free'd before exit, and the first block (i.e., the operator-specific
block of code) is the appropriate place to free things.
Please adopt this convention in any future code modifications.
I've begun leak-proofing ncap (hopeless, for now), ncwa (scary),
and ncra (looks fairly straightforward).
The clean-up requires cleanly separating system memory from process
memory (basically done), and re-writing some old core code (e.g.,
list-handling, file-handling, limits).
Cleaning up this core code requires changes to all the operators.
I try to keep the regression test working at every commit.
If you notice any failures, please let me know!
Charlie
FYI I just committed a second round of memory cleanups.
Now ncpdq and ncbo appear faultless.
Still working on ncra and then will try ncwa.
Latest changes include re-vamping of lmt structure code.
Changes to API from this are described in ChangeLog.
Charlie