We are using HDF 1.8.5 compiled with Visual Studio 2010 on windows
2000 32 bit, and getting a bad pointer when trying to read the name
for a group attribute. The program crashes on gAttriName.compare
because gAttriName is a bad pointer. It is confusing because the
number of attributes read for the group is correct it just seems like
it cannot read the attribute name for some reason. Any thoughts?
ThanksPortion of code
//--------------------------------------------------------------------
------
// Open the group name where datasets are stored in the file
//--------------------------------------------------------------------
------
Group group = file.openGroup(GRP_NAME.c_str());int k;
// loop through all the atttributes in the group
for (k = 0; k < group.getNumAttrs(); k++)
{
//--------------------------------------------------------------------
--
// store the group's attributes in attri
//--------------------------------------------------------------------
--
Attribute attri = group.openAttribute(k);
string gAttriName = attri.getName();if (gAttriName.compare("Attribute Name")==0)
{
// Do something
}}
Jeremy
Hi Jeremy. I have seen issues that point to a problem with the HDF5 C++ APIs
and the microsoft RTL std::string type.
See my post
http://hdf-forum.184993.n3.nabble.com/Access-violation-writing-string-attributes-using-VC-2005-HDF5-1-8-5-tp1785421p1785421.html
for problems when writing string attributes using the c_str() pointer
returned from a string object (at a time when this should be valid).
Also, I've not posted this one, but in my code I have a temporary workaround
macro as below to avoid similar problems with variable length string
attribute types:
#define TLF_MAX_ATTRIBUTE_STRLEN 250 //until we sort out variable length
attrs.
//some macros and inlines to boilerplate writing attributes
#define TMS_HDF_VLSTR_VAR(varname) H5::StrType
varname(0,H5T_VARIABLE)//CAUTION: causes AV when writing attr
#define TMS_HDF_STR_VAR(varname) H5::StrType varname(0,
TLF_MAX_ATTRIBUTE_STRLEN)
I've not had the time to bottom these out, but I suspect a problem with
dangling pointers somewhere in the HDF5 / USOFT RTL layers.
What I would recommend is to use a C string: below is code I've used to read
string attribute VALUES (not quite the same as what you are trying to do,
but it should give you a clue) - use the hid of the attribute object and the
underlying C APIs, which do seem to work:
//similar inlines for reading attributes, which must exist.
inline void readAttr(hid_t objId, const H5::AtomType & localVar, const char
* attName, void * pResult)
{
hid_t attr_id = H5Aopen(objId, attName, H5P_DEFAULT);
if (attr_id < 0) throw(std::string("Attribute not found: ") + attName);
herr_t stat = H5Aread(attr_id, localVar.getId(), pResult);
H5Aclose(attr_id);
if (stat < 0) throw(std::string("Failed to read attribute: ") + attName);
}
...
inline void readAttrStr(hid_t objId, const char * attName, std::string &
result)
{
TMS_HDF_STR_VAR(localVar);
char tmp[TLF_MAX_ATTRIBUTE_STRLEN];
readAttr(objId, localVar, attName, tmp);
result = const_cast<const char*>(tmp);
}
If using the C APIs and c strings avoids your bad pointer crash, then I
suspect you're seeing the same underlying problem that I saw. Don't forget
to close any temporay hids, the C api doesn't look after that for you, and
leaking hids causes performance problems.
Steve
···
--
View this message in context: http://hdf-forum.184993.n3.nabble.com/Can-t-Read-Group-Attribute-Name-VS2010-tp2229912p2233676.html
Sent from the hdf-forum mailing list archive at Nabble.com.