For those of you using valgrind you might be interested to know that
1. A mac version has just been merged into the valgrind svn trunk
(and it seems to work reasonably well)
2. --track-origins recently turned up. This shows you where
unitialised variables come from without you having to work so hard at
finding out which particular variable was uninititialised.
For example, I've always wondered about that HDS write(buf) warning:
==32737== Syscall param write(buf) points to uninitialised byte(s)
==32737== at 0x3BDFCC5570: __write_nocancel (in /lib64/libc-2.5.so)
==32737== by 0x3BDFC6BA62: _IO_file_write@@GLIBC_2.2.5 (in /lib64/
libc-2.5.so)
==32737== by 0x3BDFC6B975: _IO_do_write@@GLIBC_2.2.5 (in /lib64/
libc-2.5.so)
==32737== by 0x3BDFC6D4F8: _IO_switch_to_get_mode (in /lib64/
libc-2.5.so)
==32737== by 0x3BDFC6BC57: _IO_file_seekoff@@GLIBC_2.2.5 (in /lib64/
libc-2.5.so)
==32737== by 0x3BDFC69C19: fseeko (in /lib64/libc-2.5.so)
==32737== by 0x117F5363: rec1_write_file (rec1_write_file.c:190)
==32737== by 0x117F1BB4: rec1_flush_block (rec1_flush_block.c:74)
==32737== by 0x117F462F: rec1_unlock_slot (rec1_unlock_slot.c:170)
==32737== by 0x117F0BE5: rec1_close_slot (rec1_close_slot.c:81)
==32737== by 0x117F79E0: rec_stop (rec_stop.c:105)
==32737== by 0x117ECF2E: hds1_cleanup (hds1_cleanup.c:98)
==32737== Address 0xc62b01f is not stack'd, malloc'd or (recently)
free'd
==32737== Uninitialised value was created by a stack allocation
==32737== at 0x117F4594: rec1_unlock_slot (rec1_unlock_slot.c:30)
and it seems that rec1_unlock_slot is at fault for it (the above is
just from doing stats on comwest.sdf).
--
Tim Jenness
Joint Astronomy Centre
|