Question regarding H5Ewalk2 and H5Eget_msg.

Hdf-forum archives
1

Hi,

I wish to trap the cause of error messages rather than having them print to stderr and I figured that the best way of doing this was using a callback as outlined on this page:

    http://www.hdfgroup.org/HDF5/doc/UG/13_ErrorHandling.html

However, there appears to be a relatively serious bug, either in the example or in the implementation of some of the H5E functions. In version 1.8.2 and 1.8.3 the calls to the H5Eget methods from the callback clear the error stack and so corrupt the contents of 'err_desc':

    herr_t
    custom_print_cb(unsigned n, const H5E_error2_t *err_desc, void* client_data)
    {
        FILE *stream = (FILE *)client_data;
        char maj[MSG_SIZE];
        char min[MSG_SIZE];
        char cls[MSG_SIZE];
        const int indent = 4;

        /* Get descriptions for the major and minor error numbers */
        if(H5Eget_class_name(err_desc->cls_id, cls, MSG_SIZE)<0)
            TEST_ERROR;

The above call results in the usage of FUNC_ENTER_API which clears the error stack that is currently being navigated:

    ssize_t
    H5Eget_class_name(hid_t class_id, char *name, size_t size)
    {
        H5E_cls_t *cls; /* Pointer to error class */
        ssize_t ret_value; /* Return value */

        FUNC_ENTER_API(H5Eget_class_name, FAIL)

Now that I understand the cause, I can change how I'm using the API, so that my walk function only "stores" the information passed in via the "err_desc" parameter, however, either the behaviour of "H5Eget_msg" needs to be changed, or at a minimum the example/documentation need to be updated appropriately.

Kind Regards,

Richard

2

Hi Richard,

···

On May 12, 2009, at 7:49 AM, Richard Corden wrote:

Hi,

I wish to trap the cause of error messages rather than having them print to stderr and I figured that the best way of doing this was using a callback as outlined on this page:

    http://www.hdfgroup.org/HDF5/doc/UG/13_ErrorHandling.html

However, there appears to be a relatively serious bug, either in the example or in the implementation of some of the H5E functions. In version 1.8.2 and 1.8.3 the calls to the H5Eget methods from the callback clear the error stack and so corrupt the contents of 'err_desc':
herr_t
custom_print_cb(unsigned n, const H5E_error2_t *err_desc, void* client_data)
{
    FILE *stream = (FILE *)client_data;
    char maj[MSG_SIZE];
    char min[MSG_SIZE];
    char cls[MSG_SIZE];
    const int indent = 4;

    /* Get descriptions for the major and minor error numbers */
    if(H5Eget_class_name(err_desc->cls_id, cls, MSG_SIZE)<0)
        TEST_ERROR;
The above call results in the usage of FUNC_ENTER_API which clears the error stack that is currently being navigated:
ssize_t
H5Eget_class_name(hid_t class_id, char *name, size_t size)
{
    H5E_cls_t *cls; /* Pointer to error class */
    ssize_t ret_value; /* Return value */

    FUNC_ENTER_API(H5Eget_class_name, FAIL)

Now that I understand the cause, I can change how I'm using the API, so that my walk function only "stores" the information passed in via the "err_desc" parameter, however, either the behaviour of "H5Eget_msg" needs to be changed, or at a minimum the example/documentation need to be updated appropriately.

  Yes, we should update the documentation here. Also, you could change your usage so that you made a copy of the error stack (with H5Eget_current_stack) before walking it.

  Quincey

3

Quincey Koziol wrote:

Now that I understand the cause, I can change how I'm using the API, so that my walk function only "stores" the information passed in via the "err_desc" parameter, however, either the behaviour of "H5Eget_msg" needs to be changed, or at a minimum the example/documentation need to be updated appropriately.

Yes, we should update the documentation here. Also, you could change your usage so that you made a copy of the error stack (with H5Eget_current_stack) before walking it.

That's even better!

Thanks for your help.

Richard

···

Quincey