Mark, This should be fixed in upcoming 1.8.6 release (October 15). Hopefully a pre-released tar ball will be available for testing next week. We will announce it on FORUM.
Elena On Sep 18, 2010, at 5:09 PM, Mark Miller wrote: > FYI, I've been seeing same memcpy src/dst overlap problem on our BG/P > system. It seems to be happening in one of the first attributes ever > written to the file, a tiny single 4 byte integer value'd attribute. The > pointer for both src and dst is the same value. > > I cannot find a way to re-produce on something 'small'. > > Mark > > On Tue, 2010-08-24 at 06:13, Quincey Koziol wrote: >> Hi marc, >> >> On Aug 24, 2010, at 7:32 AM, Marc POINOT wrote: >> >>> Quincey Koziol wrote: >>>> Your code looks reasonable. We've been working on valgrind issues >>>> recently - can you check out the latest code from: >>>> http://*svn.hdfgroup.uiuc.edu/hdf5/branches/hdf5_1_8/ >>>> See if these recent changes help. >>> >>> Great, this removes all Valgrind weird messages I had on some hdf5 calls. >> >> Good! :-) >> >>> There's still one I'm investigating now (see below), only one test in my >>> test suite >>> raises this message, I'm trying to find out what's different in this test. >>> >>> ==24685== Syscall param write(buf) points to uninitialised byte(s) >>> ==24685== at 0x3E5070B012: __write_nocancel (in >>> /lib64/tls/libpthread-2.3.4.so) >>> ==24685== by 0x4C589C4: H5FD_sec2_write (H5FDsec2.c:839) >>> ==24685== by 0x4C4E603: H5FD_write (H5FDint.c:184) >>> ==24685== by 0x4C32FC4: H5F_accum_write (H5Faccum.c:580) >>> ==24685== by 0x4C34F7F: H5F_block_write (H5Fio.c:162) >>> ==24685== by 0x4D2158F: H5O_flush (H5Ocache.c:486) >>> ==24685== by 0x4BD765D: H5C_flush_single_entry (H5C.c:7606) >>> ==24685== by 0x4BC9F84: H5C_flush_cache (H5C.c:1801) >>> ==24685== by 0x4BA1EB6: H5AC_flush (H5AC.c:843) >>> ==24685== by 0x4C2CA29: H5F_flush (H5F.c:1685) >>> ==24685== by 0x4C2A044: H5F_dest (H5F.c:994) >>> ==24685== by 0x4C2D2F3: H5F_try_close (H5F.c:1909) >>> ==24685== Address 0x534713C is 6,852 bytes inside a block of size 8,192 >>> alloc'd >>> ==24685== at 0x4905E12: realloc (vg_replace_malloc.c:306) >>> ==24685== by 0x4CFCA97: H5MM_realloc (H5MM.c:140) >>> ==24685== by 0x4C320C2: H5F_accum_adjust (H5Faccum.c:335) >>> ==24685== by 0x4C32558: H5F_accum_write (H5Faccum.c:416) >>> ==24685== by 0x4C34F7F: H5F_block_write (H5Fio.c:162) >>> ==24685== by 0x4D2158F: H5O_flush (H5Ocache.c:486) >>> ==24685== by 0x4BD765D: H5C_flush_single_entry (H5C.c:7606) >>> ==24685== by 0x4BCA036: H5C_flush_cache (H5C.c:1824) >>> ==24685== by 0x4BA1EB6: H5AC_flush (H5AC.c:843) >>> ==24685== by 0x4C2CA29: H5F_flush (H5F.c:1685) >>> ==24685== by 0x4C2A044: H5F_dest (H5F.c:994) >>> ==24685== by 0x4C2D2F3: H5F_try_close (H5F.c:1909) >> >> Well, I didn't say we were completely done yet. ;-) If you can get >> this warning (which is most likely harmless) down to a simple program, I can >> see about fixing it. >> >> Quincey >> >> >> _______________________________________________ >> Hdf-forum is for HDF software users discussion. >> [email protected] >> http://*mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org > -- > Mark C. Miller, Lawrence Livermore National Laboratory > ================!!LLNL BUSINESS ONLY!!================ > [email protected] urgent: [email protected] > T:8-6 (925)-423-5901 M/W/Th:7-12,2-7 (530)-753-8511 > > > _______________________________________________ > Hdf-forum is for HDF software users discussion. > [email protected] > http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
