[netCDF #HKX-214469]: [netcdfgroup] Bug in ncdump -v

John,

> > Thanks for this fix. The explanation of how it worked for me is that that
> > fix was already in a later version of the code than you were using, and I
> > had neglected to check it in to the snapshot, so apologies if this wasted
> > your time.
> Only an afternoon. But I now know soooo much about GNU malloc. Out by 1 
> errors 
> like this are hard to track down, as they are only seen if the string length 
> is the actual allocated length. Allocated blocks are aligned on 8 byte 
> (32-bit systems) or 16-byte (64-bit systems) boundaries, so in many cases the 
> terminal NULL will be written in the alignment 'slack' and not be detected.
> That's why it worked for me in some cases but not in others. Do you 
> use -lmcheck or MALLOC_CHECK_?

Yes, I usually use a Solaris 10 x86 system for development and
debugging, and it's unfortunately liberal with mallocs, allocating
more space than you asked for so such errors can go undetected. To
work around that problem I either use valgrind on a Linux system or
the equivalent bcheck (or dbx with a "check -all") command on Solaris.
Unfortunately, the latter stopped working for me recently but was
fixed again by a system upgrade, so that's what I'll be using from now
on to plug the remaining leaks and access problems.  Also valgrind was
just ported tto MacOS X, so I've downloaded tthat and it also seems to
work well on detecting these sorts of errors.

--Russ



Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: HKX-214469
Department: Support netCDF
Priority: High
Status: Closed