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.

Sign up for GitHub

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

Jump to bottom

nc_test/nc_test fails valgrind #915

Closed
edhartnett opened this issue Mar 29, 2018 · 17 comments
Closed

nc_test/nc_test fails valgrind #915

edhartnett opened this issue Mar 29, 2018 · 17 comments

Comments

@edhartnett
Copy link
Contributor

Test nc_test4/tst_fill_attr_vanish fails valgrind like this:

ed@mikado:~/tmp/netcdf-c/nc_test4$ valgrind --leak-check=full ./tst_fill_attr_vanish
==1021== Memcheck, a memory error detector
==1021== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1021== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1021== Command: ./tst_fill_attr_vanish
==1021== 

*** Testing for a netCDF-4 fill-value bug.
*** Creating a file with no _FillValue defined. ***
==1021== Invalid read of size 1
==1021==    at 0x4C32D04: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1021==    by 0x5EDF471: puts (ioputs.c:35)
==1021==    by 0x10F287: main (tst_fill_attr_vanish.c:84)
==1021==  Address 0x6dc713a is 0 bytes after a block of size 42 alloc'd
==1021==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1021==    by 0x10F1DD: main (tst_fill_attr_vanish.c:81)
==1021== 
**** Checking that attribute still exists:	This is a text attribute used for testing.
**** Expecting NC_ELATEFILL when adding _FillValue attribute if variable exists.
==1021== Invalid read of size 1
==1021==    at 0x4C32D04: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1021==    by 0x5EDF471: puts (ioputs.c:35)
==1021==    by 0x10F3DF: main (tst_fill_attr_vanish.c:104)
==1021==  Address 0x6dc741a is 0 bytes after a block of size 42 alloc'd
==1021==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1021==    by 0x10F335: main (tst_fill_attr_vanish.c:101)
==1021== 
**** Checking that attribute still exists, pre-write:	This is a text attribute used for testing.
**** Saving, closing file.
*** Reopening file.
==1021== Invalid read of size 1
==1021==    at 0x4C32D04: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1021==    by 0x5EDF471: puts (ioputs.c:35)
==1021==    by 0x10F680: main (tst_fill_attr_vanish.c:124)
==1021==  Address 0x6eddf0a is 0 bytes after a block of size 42 alloc'd
==1021==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1021==    by 0x10F5D6: main (tst_fill_attr_vanish.c:121)
==1021== 
**** Checking that attribute still exists:	This is a text attribute used for testing.
ok.
*** Tests successful!
==1021== 
==1021== HEAP SUMMARY:
==1021==     in use at exit: 544 bytes in 31 blocks
==1021==   total heap usage: 4,834 allocs, 4,803 frees, 3,836,054 bytes allocated
==1021== 
==1021== LEAK SUMMARY:
==1021==    definitely lost: 0 bytes in 0 blocks
==1021==    indirectly lost: 0 bytes in 0 blocks
==1021==      possibly lost: 0 bytes in 0 blocks
==1021==    still reachable: 544 bytes in 31 blocks
==1021==         suppressed: 0 bytes in 0 blocks
==1021== Reachable blocks (those to which a pointer was found) are not shown.
==1021== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1021== 
==1021== For counts of detected and suppressed errors, rerun with: -v
==1021== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
@edhartnett
Copy link
Contributor Author

After cleaning up the test a bit, I still have the remaining issues. @DennisHeimbigner these have to do with the rc file. Apparently the resources malloced for it are never freed.

Where should they be freed? When the last open file is closed?

==23657== HEAP SUMMARY:
==23657==     in use at exit: 544 bytes in 31 blocks
==23657==   total heap usage: 4,834 allocs, 4,803 frees, 3,836,054 bytes allocated
==23657== 
==23657== 5 bytes in 1 blocks are still reachable in loss record 1 of 7
==23657==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23657==    by 0x1687FD: NCDISPATCH_initialize (ddispatch.c:90)
==23657==    by 0x167EE8: nc_initialize (nc_initialize.c:83)
==23657==    by 0x111CFC: NC_create (dfile.c:1821)
==23657==    by 0x11123A: nc__create (dfile.c:572)
==23657==    by 0x1111F3: nc_create (dfile.c:499)
==23657==    by 0x10EA8F: main (tst_fill_attr_vanish.c:47)
==23657== 
==23657== 9 bytes in 1 blocks are still reachable in loss record 2 of 7
==23657==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23657==    by 0x168933: NCDISPATCH_initialize (ddispatch.c:117)
==23657==    by 0x167EE8: nc_initialize (nc_initialize.c:83)
==23657==    by 0x111CFC: NC_create (dfile.c:1821)
==23657==    by 0x11123A: nc__create (dfile.c:572)
==23657==    by 0x1111F3: nc_create (dfile.c:499)
==23657==    by 0x10EA8F: main (tst_fill_attr_vanish.c:47)
==23657== 
==23657== 24 bytes in 1 blocks are still reachable in loss record 3 of 7
==23657==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23657==    by 0x170D90: nclistnew (nclist.c:30)
==23657==    by 0x16994A: rccompile (drc.c:277)
==23657==    by 0x16935E: NC_rcload (drc.c:94)
==23657==    by 0x168A1E: NCDISPATCH_initialize (ddispatch.c:134)
==23657==    by 0x167EE8: nc_initialize (nc_initialize.c:83)
==23657==    by 0x111CFC: NC_create (dfile.c:1821)
==23657==    by 0x11123A: nc__create (dfile.c:572)
==23657==    by 0x1111F3: nc_create (dfile.c:499)
==23657==    by 0x10EA8F: main (tst_fill_attr_vanish.c:47)
==23657== 
==23657== 43 bytes in 9 blocks are still reachable in loss record 4 of 7
==23657==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23657==    by 0x5EFAC99: strdup (strdup.c:42)
==23657==    by 0x169BB9: rccompile (drc.c:331)
==23657==    by 0x16935E: NC_rcload (drc.c:94)
==23657==    by 0x168A1E: NCDISPATCH_initialize (ddispatch.c:134)
==23657==    by 0x167EE8: nc_initialize (nc_initialize.c:83)
==23657==    by 0x111CFC: NC_create (dfile.c:1821)
==23657==    by 0x11123A: nc__create (dfile.c:572)
==23657==    by 0x1111F3: nc_create (dfile.c:499)
==23657==    by 0x10EA8F: main (tst_fill_attr_vanish.c:47)
==23657== 
==23657== 119 bytes in 9 blocks are still reachable in loss record 5 of 7
==23657==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23657==    by 0x5EFAC99: strdup (strdup.c:42)
==23657==    by 0x169BA2: rccompile (drc.c:330)
==23657==    by 0x16935E: NC_rcload (drc.c:94)
==23657==    by 0x168A1E: NCDISPATCH_initialize (ddispatch.c:134)
==23657==    by 0x167EE8: nc_initialize (nc_initialize.c:83)
==23657==    by 0x111CFC: NC_create (dfile.c:1821)
==23657==    by 0x11123A: nc__create (dfile.c:572)
==23657==    by 0x1111F3: nc_create (dfile.c:499)
==23657==    by 0x10EA8F: main (tst_fill_attr_vanish.c:47)
==23657== 
==23657== 128 bytes in 1 blocks are still reachable in loss record 6 of 7
==23657==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23657==    by 0x170F0B: nclistsetalloc (nclist.c:72)
==23657==    by 0x171246: nclistpush (nclist.c:136)
==23657==    by 0x169BF7: rccompile (drc.c:339)
==23657==    by 0x16935E: NC_rcload (drc.c:94)
==23657==    by 0x168A1E: NCDISPATCH_initialize (ddispatch.c:134)
==23657==    by 0x167EE8: nc_initialize (nc_initialize.c:83)
==23657==    by 0x111CFC: NC_create (dfile.c:1821)
==23657==    by 0x11123A: nc__create (dfile.c:572)
==23657==    by 0x1111F3: nc_create (dfile.c:499)
==23657==    by 0x10EA8F: main (tst_fill_attr_vanish.c:47)
==23657== 
==23657== 216 bytes in 9 blocks are still reachable in loss record 7 of 7
==23657==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23657==    by 0x1699C1: rccompile (drc.c:293)
==23657==    by 0x16935E: NC_rcload (drc.c:94)
==23657==    by 0x168A1E: NCDISPATCH_initialize (ddispatch.c:134)
==23657==    by 0x167EE8: nc_initialize (nc_initialize.c:83)
==23657==    by 0x111CFC: NC_create (dfile.c:1821)
==23657==    by 0x11123A: nc__create (dfile.c:572)
==23657==    by 0x1111F3: nc_create (dfile.c:499)
==23657==    by 0x10EA8F: main (tst_fill_attr_vanish.c:47)
==23657== 
==23657== LEAK SUMMARY:
==23657==    definitely lost: 0 bytes in 0 blocks
==23657==    indirectly lost: 0 bytes in 0 blocks
==23657==      possibly lost: 0 bytes in 0 blocks
==23657==    still reachable: 544 bytes in 31 blocks
==23657==         suppressed: 0 bytes in 0 blocks
==23657== 
==23657== For counts of detected and suppressed errors, rerun with: -v
==23657== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

@edhartnett edhartnett changed the title nc_test4/tst_fill_attr_vanish fails valgrind nc_test/nc_test, nc_test4/tst_fill_attr_vanish fails valgrind Mar 29, 2018
@edhartnett
Copy link
Contributor Author

This same issue is also affecting nc_test, which fails like this:

==16846== HEAP SUMMARY:
==16846==     in use at exit: 544 bytes in 31 blocks
==16846==   total heap usage: 24,520,596 allocs, 24,520,565 frees, 2,525,885,957 bytes allocated
==16846== 
==16846== 5 bytes in 1 blocks are still reachable in loss record 1 of 7
==16846==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16846==    by 0x221ECB: NCDISPATCH_initialize (ddispatch.c:90)
==16846==    by 0x2215C9: nc_initialize (nc_initialize.c:78)
==16846==    by 0x1C6538: NC_create (dfile.c:1772)
==16846==    by 0x1C5A76: nc__create (dfile.c:527)
==16846==    by 0x1C5A2F: nc_create (dfile.c:454)
==16846==    by 0x1C1725: file_create (util.c:1166)
==16846==    by 0x1C0464: write_file (util.c:918)
==16846==    by 0x10F05F: main (nc_test.c:173)
==16846== 
==16846== 9 bytes in 1 blocks are still reachable in loss record 2 of 7
==16846==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16846==    by 0x222001: NCDISPATCH_initialize (ddispatch.c:117)
==16846==    by 0x2215C9: nc_initialize (nc_initialize.c:78)
==16846==    by 0x1C6538: NC_create (dfile.c:1772)
==16846==    by 0x1C5A76: nc__create (dfile.c:527)
==16846==    by 0x1C5A2F: nc_create (dfile.c:454)
==16846==    by 0x1C1725: file_create (util.c:1166)
==16846==    by 0x1C0464: write_file (util.c:918)
==16846==    by 0x10F05F: main (nc_test.c:173)
==16846== 
==16846== 24 bytes in 1 blocks are still reachable in loss record 3 of 7
==16846==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16846==    by 0x225E2C: nclistnew (nclist.c:30)
==16846==    by 0x222DA2: rccompile (drc.c:277)
==16846==    by 0x2227B6: NC_rcload (drc.c:94)
==16846==    by 0x2220EC: NCDISPATCH_initialize (ddispatch.c:134)
==16846==    by 0x2215C9: nc_initialize (nc_initialize.c:78)
==16846==    by 0x1C6538: NC_create (dfile.c:1772)
==16846==    by 0x1C5A76: nc__create (dfile.c:527)
==16846==    by 0x1C5A2F: nc_create (dfile.c:454)
==16846==    by 0x1C1725: file_create (util.c:1166)
==16846==    by 0x1C0464: write_file (util.c:918)
==16846==    by 0x10F05F: main (nc_test.c:173)
==16846== 
==16846== 43 bytes in 9 blocks are still reachable in loss record 4 of 7
==16846==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16846==    by 0x5EFAC99: strdup (strdup.c:42)
==16846==    by 0x223011: rccompile (drc.c:331)
==16846==    by 0x2227B6: NC_rcload (drc.c:94)
==16846==    by 0x2220EC: NCDISPATCH_initialize (ddispatch.c:134)
==16846==    by 0x2215C9: nc_initialize (nc_initialize.c:78)
==16846==    by 0x1C6538: NC_create (dfile.c:1772)
==16846==    by 0x1C5A76: nc__create (dfile.c:527)
==16846==    by 0x1C5A2F: nc_create (dfile.c:454)
==16846==    by 0x1C1725: file_create (util.c:1166)
==16846==    by 0x1C0464: write_file (util.c:918)
==16846==    by 0x10F05F: main (nc_test.c:173)
==16846== 
==16846== 119 bytes in 9 blocks are still reachable in loss record 5 of 7
==16846==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16846==    by 0x5EFAC99: strdup (strdup.c:42)
==16846==    by 0x222FFA: rccompile (drc.c:330)
==16846==    by 0x2227B6: NC_rcload (drc.c:94)
==16846==    by 0x2220EC: NCDISPATCH_initialize (ddispatch.c:134)
==16846==    by 0x2215C9: nc_initialize (nc_initialize.c:78)
==16846==    by 0x1C6538: NC_create (dfile.c:1772)
==16846==    by 0x1C5A76: nc__create (dfile.c:527)
==16846==    by 0x1C5A2F: nc_create (dfile.c:454)
==16846==    by 0x1C1725: file_create (util.c:1166)
==16846==    by 0x1C0464: write_file (util.c:918)
==16846==    by 0x10F05F: main (nc_test.c:173)
==16846== 
==16846== 128 bytes in 1 blocks are still reachable in loss record 6 of 7
==16846==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16846==    by 0x225FA7: nclistsetalloc (nclist.c:72)
==16846==    by 0x2262E2: nclistpush (nclist.c:136)
==16846==    by 0x22304F: rccompile (drc.c:339)
==16846==    by 0x2227B6: NC_rcload (drc.c:94)
==16846==    by 0x2220EC: NCDISPATCH_initialize (ddispatch.c:134)
==16846==    by 0x2215C9: nc_initialize (nc_initialize.c:78)
==16846==    by 0x1C6538: NC_create (dfile.c:1772)
==16846==    by 0x1C5A76: nc__create (dfile.c:527)
==16846==    by 0x1C5A2F: nc_create (dfile.c:454)
==16846==    by 0x1C1725: file_create (util.c:1166)
==16846==    by 0x1C0464: write_file (util.c:918)
==16846== 
==16846== 216 bytes in 9 blocks are still reachable in loss record 7 of 7
==16846==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16846==    by 0x222E19: rccompile (drc.c:293)
==16846==    by 0x2227B6: NC_rcload (drc.c:94)
==16846==    by 0x2220EC: NCDISPATCH_initialize (ddispatch.c:134)
==16846==    by 0x2215C9: nc_initialize (nc_initialize.c:78)
==16846==    by 0x1C6538: NC_create (dfile.c:1772)
==16846==    by 0x1C5A76: nc__create (dfile.c:527)
==16846==    by 0x1C5A2F: nc_create (dfile.c:454)
==16846==    by 0x1C1725: file_create (util.c:1166)
==16846==    by 0x1C0464: write_file (util.c:918)
==16846==    by 0x10F05F: main (nc_test.c:173)
==16846== 
==16846== LEAK SUMMARY:
==16846==    definitely lost: 0 bytes in 0 blocks
==16846==    indirectly lost: 0 bytes in 0 blocks
==16846==      possibly lost: 0 bytes in 0 blocks
==16846==    still reachable: 544 bytes in 31 blocks
==16846==         suppressed: 0 bytes in 0 blocks
==16846==

@DennisHeimbigner
Copy link
Collaborator

The problem is that there a number of global pieces of data that
are allocated once when the netcdf-c library is initialized.
These include the rc data plus other things like stride 1 constants.
There is no publically defined way to free up this data because
we do not know when the user is finished with the library.

However... I did define a HIDDEN nc_finallze() function that will free
up this global memory. I use it in some of our test cases when I
need them to be memory-clean.

I am still of two minds about adding this function to netcdf.h
Note that we do not need to add nc_initialize because we can automatically
invoke it upon first use of the library.

@edhartnett
Copy link
Contributor Author

How about we maintain a counter of open files.

When count goes from 1 to 0, nc_close() calls nc_finalize().

When count goes from 0 to 1, nc_open/nc_create call nc_initialize()?

It would be a bummer if we had to introduced nc_finaize() as a public function. I think we can keep track of when it needs to be called, and spare the user knowledge of it.

@gsjaardema
Copy link
Contributor

I could see that getting called much too often. There are times when we open multiple (in the hundreds to thousands) of files. At times this needs to be done one-at-a-time so we would be calling nc_initialize() / nc_finalize() hundreds to thousands of times per run which probably isn't optimal just to save a valgrind warning for memory that will be destroyed by the operating system a millisecond later...

I think that some libraries register a function with atexit() . The program then calls this function at program exit. Not sure how portable this is, but I have seen it in multiple libraries; I think it is used or was used in HDF5.

@DennisHeimbigner
Copy link
Collaborator

Since atexit() is available under windows and, apparently, OS/X, it is probably
feasible to add it, but my question is: will valgrind see it? That is, when does
valgrind report unfree'd global data?

@gsjaardema
Copy link
Contributor

Valgrind will see it. Valgrind checks after program exit.

@edhartnett
Copy link
Contributor Author

OK, I withdraw my objection to nc_finalize(). What if we make it public and optional. Only users who want to clean up all memory (as for valgrind runs) need bother with it?

I will add it to some of the tests that are failing valgrind and see if it sorts them out...

@edhartnett
Copy link
Contributor Author

But hold on. If this is a case of memory that was allocated in nc_initialize(), then how come only a couple of tests are affected? Seems like every test should report this problem, if it is because of normal operation of nc_initialize().

Also, I cleaned up tst_fill_attr_vanish.c a bit, and now I am no longer seeing the problem there. Which is interesteing because I didn't think that anything in my clean-up of the test would fix the leak. I will continue to investigate.

@DennisHeimbigner
Copy link
Collaborator

I don't think that valgrind considers the global data case an
error, but it does report it. So if you directly use valgrind, you will probably
see the report even using make check-valgrind suceeds.
The global buffer overflow was caused by a bad memcpy call with a too-big
size.

@DennisHeimbigner
Copy link
Collaborator

DennisHeimbigner commented Mar 29, 2018 •
edited
Loading

Also, I am creating a PR to enable using atexit() since it seems to be generally
available. I will, for now, make it disabled by default, but it can be turned on
using --enable-library-finalize option. This should make it unnecessary to make
nc_finalize public.

@edhartnett
Copy link
Contributor Author

@DennisHeimbigner I believe you are correct. Valgrind complains in output about global data, but doesn't fail for it.

Here's what is really causing nc_test to fail. Looks like I spoke too soon about not finding memory issues in the classic code. This happens to 64-bit offset format, but not classic:

*** testing nc_put_att_schar ... ==10589== Conditional jump or move depends on uninitialised value(s)
==10589==    at 0x1D6F6F: ncx_get_uint_schar (ncx.m4:1166)
==10589==    by 0x1E176D: ncx_getn_uint_schar (ncx.m4:3350)
==10589==    by 0x22BD3E: ncx_pad_getn_Ischar (attr.m4:726)
==10589==    by 0x22DD5D: NC3_get_att (attr.m4:986)
==10589==    by 0x1C1D28: nc_get_att_schar (dattget.c:203)
==10589==    by 0x1659E3: check_atts_schar (test_put.c:1435)
==10589==    by 0x1A2521: test_nc_put_att_schar (test_put.c:12922)
==10589==    by 0x1148AA: main (nc_test.c:357)
==10589== 
==10589== Syscall param write(buf) points to uninitialised byte(s)
==10589==    at 0x5F610C4: write (write.c:26)
==10589==    by 0x1E4EFC: px_pgout (posixio.c:306)
==10589==    by 0x1E5621: px_get (posixio.c:599)
==10589==    by 0x1E5C6F: ncio_px_get (posixio.c:787)
==10589==    by 0x1D4A7B: ncio_get (ncio.c:109)
==10589==    by 0x1E8209: fill_NC_var (putget.m4:264)
==10589==    by 0x1D26B7: fillerup (nc3internal.c:517)
==10589==    by 0x1D3284: NC_endef (nc3internal.c:922)
==10589==    by 0x1D3C4F: NC3_close (nc3internal.c:1336)
==10589==    by 0x1C5E97: nc_close (dfile.c:1312)
==10589==    by 0x1A252E: test_nc_put_att_schar (test_put.c:12923)
==10589==    by 0x1148AA: main (nc_test.c:357)
==10589==  Address 0x6db5ba8 is 456 bytes inside a block of size 16,384 alloc'd
==10589==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10589==    by 0x1E641B: ncio_px_init2 (posixio.c:1063)
==10589==    by 0x1E6EEB: posixio_create (posixio.c:1650)
==10589==    by 0x1D4985: ncio_create (ncio.c:64)
==10589==    by 0x1D36DB: NC3_create (nc3internal.c:1097)
==10589==    by 0x1C6665: NC_create (dfile.c:2027)
==10589==    by 0x1C595A: nc__create (dfile.c:572)
==10589==    by 0x1C5913: nc_create (dfile.c:499)
==10589==    by 0x1C15A7: file_create (util.c:1166)
==10589==    by 0x1A1C9E: test_nc_put_att_schar (test_put.c:12848)
==10589==    by 0x1148AA: main (nc_test.c:357)
==10589==

DennisHeimbigner added a commit that referenced this issue Mar 29, 2018
@DennisHeimbigner
Re: github issues
42e8028 
#917
#915

Fix following memory errors:
1. global_buffer_overflow
2. nc4_att_list_add
DennisHeimbigner added a commit that referenced this issue Mar 29, 2018
@DennisHeimbigner
Re: github issues
d7ad871 
#917
#915

Fix following memory errors:
1. global_buffer_overflow
2. nc4_att_list_add
@edhartnett edhartnett changed the title nc_test/nc_test, nc_test4/tst_fill_attr_vanish fails valgrind nc_test/nc_test fails valgrind Mar 30, 2018
@okey
Copy link

okey commented Oct 9, 2018

@DennisHeimbigner Have you opened a PR for --enable-library-finalize yet?

@DennisHeimbigner
Copy link
Collaborator

DennisHeimbigner commented Oct 9, 2018 •
edited
Loading

I did not bother with a formal ./configure flag;
nc_finalize should be defined in netcdf.h release 4.6.1

@DennisHeimbigner
Copy link
Collaborator

Is anyone still seeing this valgrind failure in nc_test/nc_test?
I just ran it on curren tmaster and it seems to work.

@okey
Copy link

okey commented Oct 10, 2018 •
edited
Loading

@DennisHeimbigner Thanks.

On the current master (4a5b15b), ctest -R tst_fill_attr_vanish -T memcheck passes (???) but reports the following:

1/1 MemCheck: #120: nc_test4_tst_fill_attr_vanish ....   Defects: 35
Memory checking results:
Memory Leak - 3
Potential Memory Leak - 29
Uninitialized Memory Read - 3

Log attached:
MemoryChecker.120.log

@edhartnett
Copy link
Contributor Author

valgrind builds have been passing in my CI for a while now. I will close this ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@okey @gsjaardema @DennisHeimbigner @edhartnett