This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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