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

John,

> Found it. How it worked for you on my sample file I'll never know.
> In dumplib.c, nc_inq_gvarid(),
> groupname = (char *)emalloc(len);
> should be
> groupname = (char *)emalloc(len + 1);

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.

> There may be other issues, but it's 8pm here and I'm going home.

There are some other issues pointed out by running a memory checker
on the code, so I'll be doing a cleanup of the code and memory leaks later
today.

--Russ

> On Wednesday 10 June 2009, you wrote:
> > Hi John,
> >
> > > This is a bit worrying. 'ncdump -v time1 xma022032.nc' works, but
> > > here's a gdb backtrace for 'ncdump -v xma/obv01 xma022032.nc'
> > >
> > > Program received signal SIGABRT, Aborted.
> > > 0x4001b402 in __kernel_vsyscall ()
> > > (gdb) bt
> > > #0  0x4001b402 in __kernel_vsyscall ()
> > > #1  0x40359d40 in raise () from /lib/libc.so.6
> > > #2  0x4035b591 in abort () from /lib/libc.so.6
> > > #3  0x4038f18b in __libc_message () from /lib/libc.so.6
> > > #4  0x40396efd in _int_free () from /lib/libc.so.6
> > > #5  0x4039a550 in free () from /lib/libc.so.6
> > > #6  0x08051929 in nc_inq_gvarid (grpid=65540, varname=0x4046b120 "\001",
> > > varidp=0x8cbd4c0) at dumplib.c:1553
> > > #7  0x0804bf62 in nc_inq_varname_count (ncid=65540,
> > > varname=0x8160018 "xma/obv01") at ncdump.c:1870
> > > #8  0x0804bfd3 in nc_inq_varname_count (ncid=65539,
> > > varname=0x8160018 "xma/obv01") at ncdump.c:1890
> > > #9  0x0804bfd3 in nc_inq_varname_count (ncid=65537,
> > > varname=0x8160018 "xma/obv01") at ncdump.c:1890
> > > #10 0x0804bfd3 in nc_inq_varname_count (ncid=65536,
> > > varname=0x8160018 "xma/obv01") at ncdump.c:1890
> > > #11 0x0804e920 in main (argc=1, argv=0xbf879444) at ncdump.c:1905
> > > (gdb)
> > >
> > > This was using ncdump from today's snapshot to make sure I am completely
> > > up-to-date. I'm linking to hdf5-1.8.2, zlib-1.2.3, and libc.6 as you can
> > > see in the backtrace. Normal 32-bit code. Looks like a library
> > > compatibility problem.
> >
> > Sorry to be slow to respond, I'm involved in a Workshop all this week.  I'm
> > linking against hdf5-1.8.3 and still not able to reproduce the problem you
> > see above.  I've tried the valgrind utility as well, and it shows memory
> > leaks in ncdump, but the only memory access errors are within the HDF5
> > library, and I think are spurious or not significant:
> >
> > The ncdump command completes OK and the CDL file looks like what is
> > expected. I'd be interested if the problem you see persists with
> > HDF5-1.8.3.
> >
> > --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
> >
> >
> >
> > Click
> > https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==
> >Pcha0fJhlB1Q7l6e!9bxE+P8w3h9RYjieLvRJKIvyA==  to report this email as spam.
> 
> 
> 
> --
> John Storrs, Experiments Dept      e-mail: address@hidden
> Building D3, UKAEA Fusion                               tel: 01235 466338
> Culham Science Centre                                    fax: 01235 466379
> Abingdon, Oxfordshire OX14 3DB              http://www.fusion.org.uk
> 
> 
> 
> 
> This message has been scanned for viruses by BlackSpider MailControl - 
> www.blackspider.com
> 
> 

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