H5CX__pop_common fails under Linux

HDF5 Library
1

Hello, I have HDF5 working under Windows, but it fails under Linux.

The function H5CX__pop_common fails (called from H5open) because “H5CX_node_t **head = H5CX_get_my_context();” returns as “head != null && *head == null”.

I tried this with H5_HAVE_THREADSAFE and without, with the same result.

When looking at “H5CX_get_my_context” I am unsure how this function would ever not return with “*head == null”.

I cleaned up the function for easier reference here.

static H5CX_node_t ** H5CX__get_context(void)
{
    H5CX_node_t **ctx = NULL;

    FUNC_ENTER_STATIC_NOERR

    ctx = (H5CX_node_t **)H5TS_get_thread_local_value(H5TS_apictx_key_g);

    if(!ctx) {
        /* No associated value with current thread - create one */
        ctx = (H5CX_node_t **)HDmalloc(sizeof(H5CX_node_t *));
        HDassert(ctx);

        /* Reset the thread-specific info */
		*ctx = NULL;

        /* (It's not necessary to release this in this API, it is
         *      released by the "key destructor" set up in the H5TS
         *      routines.  See calls to pthread_key_create() in H5TS.c -QAK)
         */
        H5TS_set_thread_local_value(H5TS_apictx_key_g, (void *)ctx);
    } /* end if */

    /* Set return value */
    FUNC_LEAVE_NOAPI(ctx)
} /* end H5CX__get_context() */

So the function sets “*ctx = NULL;” and then calls “H5TS_set_thread_local_value” which compiles to “pthread_setspecific”, so it seems to me that “*ctx” will always be null.

Does anyone have more insight into this? Do I have to create this context explicitly?

Thank,
Daniel

2

Hello,

I started to debug into the HDF5 code and found where the whole thing goes wrong.

In H5T.c the function H5T__init_package() fails when it calls:

status |= H5T__register_int(H5T_PERS_HARD, "llong_long", native_llong, native_long, H5T__conv_llong_long);

But why this fails is beyond me, the code gets very cryptic short after that, ending in the function H5T__register, failing at the end of the following block:

if(H5T_PERS_HARD == pers) {
    /* Only bother to register the path if it's not a no-op path (for this machine) */
    if(H5T_cmp(src, dst, FALSE)) {
        /* Locate or create a new conversion path */
        if(NULL == (new_path = H5T__path_find_real(src, dst, name, conv)))
            HGOTO_ERROR(H5E_DATATYPE, H5E_CANTINIT, FAIL, "unable to locate/allocate conversion path")

Maybe someone with more insight into the library have an idea why this would happen?

Thanks,
Daniel

3

Okay, I found the problem. I use the same source file generated by the detect tool for Windows and Linux. A problem like this could be easily avoided by compile checking if the header definitions match the ones from the file.