I have got the following diagnostics when run my program with
valgrind. This was generated by H5Dwrite call on array of compound
types. Maybe somebody is familiar with this? It does not seem right!
When I remove writing call, everything is fine.
Anton
==15272== Memcheck, a memory error detector.
==15272== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==15272== Using LibVEX rev 1732, a library for dynamic binary translation.
==15272== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==15272== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==15272== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==15272== For more details, rerun with: -v
==15272==
filename: haha003.h5
==15272== Syscall param write(buf) points to uninitialised byte(s)
==15272== at 0x5607420: __write_nocancel (in /lib64/libc-2.6.so)
==15272== by 0x5164FDC: H5FD_sec2_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x515EA82: H5FD_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x514DEE8: H5F_block_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5126BDC: H5D_flush_sieve_buf (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x511F8E1: H5D_contig_flush (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5126A49: H5D_flush_real (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5127E89: H5D_close (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x51B3EC8: H5I_dec_ref (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5112B5D: H5Dclose (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x400FE1: dsio_save_astruct_1d (dsio.nw:235)
==15272== by 0x40138F: main (dsio.nw:501)
==15272== Address 0x412830C is 12 bytes inside a block of size 65,544 alloc'd
==15272== at 0x4C1F996: malloc (vg_replace_malloc.c:149)
==15272== by 0x516840B: H5FL_malloc (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5168B6C: H5FL_blk_malloc (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x51207A7: H5D_contig_writevv (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5130C24: H5D_select_io (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5130EEC: H5D_select_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x511F94C: H5D_contig_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x512CD20: H5Dwrite (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x400F6C: dsio_save_astruct_1d (dsio.nw:212)
==15272== by 0x40138F: main (dsio.nw:501)
==15272==
==15272== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 1)
==15272== malloc/free: in use at exit: 0 bytes in 0 blocks.
==15272== malloc/free: 2,199 allocs, 2,199 frees, 821,653 bytes allocated.
==15272== For counts of detected errors, rerun with: -v
==15272== All heap blocks were freed -- no leaks are possible.
I have got the following diagnostics when run my program with
valgrind. This was generated by H5Dwrite call on array of compound
types. Maybe somebody is familiar with this? It does not seem right!
When I remove writing call, everything is fine.
If you are going to use valgrind (or another memory checking tool, like Purify), you should configure the HDF5 distribution with the --enable-using-memchecker flag.
Quincey
···
On Mar 17, 2010, at 6:37 PM, Anton Kulchitsky wrote:
Anton
==15272== Memcheck, a memory error detector.
==15272== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==15272== Using LibVEX rev 1732, a library for dynamic binary translation.
==15272== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==15272== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==15272== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==15272== For more details, rerun with: -v
==15272==
filename: haha003.h5
==15272== Syscall param write(buf) points to uninitialised byte(s)
==15272== at 0x5607420: __write_nocancel (in /lib64/libc-2.6.so)
==15272== by 0x5164FDC: H5FD_sec2_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x515EA82: H5FD_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x514DEE8: H5F_block_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5126BDC: H5D_flush_sieve_buf (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x511F8E1: H5D_contig_flush (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5126A49: H5D_flush_real (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5127E89: H5D_close (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x51B3EC8: H5I_dec_ref (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5112B5D: H5Dclose (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x400FE1: dsio_save_astruct_1d (dsio.nw:235)
==15272== by 0x40138F: main (dsio.nw:501)
==15272== Address 0x412830C is 12 bytes inside a block of size 65,544 alloc'd
==15272== at 0x4C1F996: malloc (vg_replace_malloc.c:149)
==15272== by 0x516840B: H5FL_malloc (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5168B6C: H5FL_blk_malloc (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x51207A7: H5D_contig_writevv (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5130C24: H5D_select_io (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x5130EEC: H5D_select_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x511F94C: H5D_contig_write (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x512CD20: H5Dwrite (in /export/staffdata/kulchits/usr/lib/libhdf5.so.6.0.3)
==15272== by 0x400F6C: dsio_save_astruct_1d (dsio.nw:212)
==15272== by 0x40138F: main (dsio.nw:501)
==15272==
==15272== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 1)
==15272== malloc/free: in use at exit: 0 bytes in 0 blocks.
==15272== malloc/free: 2,199 allocs, 2,199 frees, 821,653 bytes allocated.
==15272== For counts of detected errors, rerun with: -v
==15272== All heap blocks were freed -- no leaks are possible.
thank you! Oh! I am sorry I missed that in ./configure --help. Does it
slow library down or put other overhead? Otherwise, I do not understand
why it is not a default behavior?
Thank you again, you helped a lot. I always use valgrind and other
memory checking tools with my programs and probably cannot work without
them.
Anton
···
Hi Anton,
On Mar 17, 2010, at 6:37 PM, Anton Kulchitsky wrote:
I have got the following diagnostics when run my program with
valgrind. This was generated by H5Dwrite call on array of compound
types. Maybe somebody is familiar with this? It does not seem right!
When I remove writing call, everything is fine.
If you are going to use valgrind (or another memory checking tool, like Purify), you should configure the HDF5 distribution with the --enable-using-memchecker flag.
thank you! Oh! I am sorry I missed that in ./configure --help. Does it
slow library down or put other overhead? Otherwise, I do not understand
why it is not a default behavior?
Yes, it removes some otherwise valid optimizations that confuse tools like valgrind.
Quincey
···
On Mar 18, 2010, at 11:33 AM, Anton Kulchitsky wrote:
Thank you again, you helped a lot. I always use valgrind and other
memory checking tools with my programs and probably cannot work without
them.
Anton
Hi Anton,
On Mar 17, 2010, at 6:37 PM, Anton Kulchitsky wrote:
I have got the following diagnostics when run my program with
valgrind. This was generated by H5Dwrite call on array of compound
types. Maybe somebody is familiar with this? It does not seem right!
When I remove writing call, everything is fine.
If you are going to use valgrind (or another memory checking tool, like Purify), you should configure the HDF5 distribution with the --enable-using-memchecker flag.
Perhaps an alternative would be to create a valgrind suppression file?
When the CMake stuff is working, we can do nightlies that run the tests
under valgrind (CMake has explicit features for valgrind). This is
hugely useful compared to testing with valgrind once in a while, but
less so if there are known false positives.
···
On Thu, 18 Mar 2010 13:30:44 -0500, Quincey Koziol said:
thank you! Oh! I am sorry I missed that in ./configure --help. Does it
slow library down or put other overhead? Otherwise, I do not understand
why it is not a default behavior?
Yes, it removes some otherwise valid optimizations that confuse tools
like valgrind.
--
____________________________________________________________
Sean McBride, B. Eng sean@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
thank you! Oh! I am sorry I missed that in ./configure --help. Does it
slow library down or put other overhead? Otherwise, I do not understand
why it is not a default behavior?
Yes, it removes some otherwise valid optimizations that confuse tools
like valgrind.
Perhaps an alternative would be to create a valgrind suppression file?
Thank you, this seems to me a good option especially because even when I
specified --enable-using-memchecker, it did not help with HDF5 writing
call. I also like the idea about nightlies with valgrind tests. It is
useful if tests run too long under valgrind.
Anton
···
On Thu, 18 Mar 2010 13:30:44 -0500, Quincey Koziol said:
When the CMake stuff is working, we can do nightlies that run the tests
under valgrind (CMake has explicit features for valgrind). This is
hugely useful compared to testing with valgrind once in a while, but
less so if there are known false positives.
