Hello Wolfgang, Thank you very much for the bug report, and thank you even more for the diagnosis/fix. We do not currently have access to an AIX environment or IBM's XL C compiler, so debugging these issues would have been very difficult. I will incorporate an explicit NULL check after malloc is called, as you suggest, and will look for similar issues. I'll also make a note of the -D_LINUX_SOURCE_COMPAT flag for the XL C compiler. Thanks again, have a great day, -Ward > Dear NetCDF team, > > I recently needed to build NetCDF 184.108.40.206 on a POWER6 machine with AIX 6.1 > and IBMâs XL C compiler V11.1. I encountered two issues and found a simple > solution for both of these. As POWER/AIX is among the more exotic platforms, > I thought Iâd send you this to share with other users, if you find it > useful. > > The issues were: > > 1. Compilation failure due to diverging function return type definitions > between prototypes and body (type âOCerrorâ vs type âintâ in oc.h, > ochttp.c, and ocrc.c in the âoc2â directory) > > 2. Test failures in the ânc_testâ suite (in the ânc_testâ > directory) due to reported malloc failures > It seems that both issues were found previously by other users (e.g. > â[netCDF #NQH-437723]: nc_test failure on aix7 power7 cluster for the > second issueâ). > > The problems stem from differences in the behaviour of the XL C compiler > compared to, e.g., the GCC compiler. They can be easily handled without > applying any code changes by using a XL C pre-processor macro that asks for > âLinux-compatibleâ compiler behaviour: > CPPFLAGS = -D_LINUX_SOURCE_COMPAT > The NetCDF package can now be built and tested without problems. > > Malloc failures: > I investigated the malloc failures in the ânc_testâ suite a bit more, > they stem from malloc(0) requests. The code generated by the XL C compiler > returns a NULL pointer for malloc(0), where GCC allocates memory. > > This situation appears under the following conditions: > > - Data is written to a variable in a NetCDF file with NetCDF4 format > using one of the ânc_put_var_xxxâ functions > > - The variable has at least one unlimited dimension with current > length 0 > > - The program attempts to write numerical data with a different type > than the variable definition, triggering automatic conversion > > This results in a âmalloc(0)â request for a memory buffer in line 660 of > source file libsrc4/nc4hdf.c. Unlike GCC, the XL C malloc returns a NULL > pointer, causing NetCDF to report a malloc failure. It seems that the C > standard allows both NULL pointers and memory allocation for a malloc(0) > request. It could therefore be useful to handle this ambiguity explicitly in > NetCDF, to avoid the error message. > > I hope that you find this useful. Please let me know if you have any > questions. > > Best regards, > > Wolfgang > > Dr Wolfgang Hayek > HPC Scientific Programmer > > +64-4-386-0810 | +64-27-801-4625 | 301 Evans Bay Parade, Greta Point, > Wellington | www.niwa.co.nz<http://www.niwa.co.nz> > [NIWA]<http://www.niwa.co.nz> > To ensure compliance with legal requirements and to maintain cyber security > standards, NIWA's IT systems are subject to ongoing monitoring, activity > logging and auditing. This monitoring and auditing service may be provided by > third parties. Such third parties can access information transmitted to, > processed by and stored on NIWA's IT systems. > > > > Ticket Details =================== Ticket ID: NQH-437723 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.