can't delete file attribute

[doutriaux1]

import cdms2
f=cdms2.open("attribute.nc","w")
f.my_Att = "Anything"
del(f.my_Att)'

gives us

Segmentation fault (core dumped)

[doutriaux1]

(gdb) r
Starting program: /lgm/uvcdat/2015-06-09/bin/python -c import\ cdms2\;f=cdms2.open\(\"attrgfdgfdgfibute.nc\",\"w\"\)\;f.my_Att\ =\ \"Anything\"\;del\(f.my_Att\)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
set_attribute (fileid=65536, varid=-1, attributes=0x7fffe4c62910, name=0x7ffff7e8cf84 "my_Att", value=0x0) at Src/Cdunifmodule.c:1043
1043      if (PyString_Check(value)) {
(gdb) quit
A debugging session is active.

[durack1]

@doutriaux1 it would be a great enhancement to add this functionality into cdms2

[durack1]

@doutriaux1 this might be something to watch too Unidata/netcdf-c#128 - it seems to be a standing issue in the netcdf-c library from the looks..

[durack1]

@doutriaux1 it's likely that #1579 (which should fix Unidata/netcdf-c#128) should deprecate this issue.. I'll pull the latest 4.4.0-rc6 (if there is one) into #1676 and hopefully this will resolve this issue (along with #1579)

[durack1]

@doutriaux1 @dnadeau4 looks like 4.4.0-rc5 hopefully fixes this following Unidata/netcdf-c#128 (comment) (a standing bug was fixed and found it's way into the rc5 candidate) - so probably a good idea to test out the existing PR #1676 and see if this issue is resolved?

[durack1]

@doutriaux1 can you test the PR #1676 and see if this solves this segfault? If not, we should be able to get back to @WardF with more specific details..

[dnadeau4]

Actually the problem was not netCDF library, but the fact that we were passing a NULL pointer to nc_put_attr_text API. when deleting an attribute with Python, set_attribute is being called and value points to NULL. This is what I fixed in #1841

[durack1]

@dnadeau4 ok, so might be a different issue.. However I still would be curious if the changes implemented in Unidata/netcdf-c#128 (comment) lead to a change in behavior down stream in Cdunif's use of the netcdf library.. Was just a curiosity, and as the branch exists, would be relatively straight forward to test..