octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #37713] HDF5 error message on exit


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #37713] HDF5 error message on exit
Date: Thu, 17 Oct 2013 05:28:31 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

Follow-up Comment #10, bug #37713 (project octave):

Don't close this one just yet.  Although I followed the links and see some
very similar bug reports for HD5, the code sequence is different from the
pattern listed here.

Here is the hunk of HD5 code (from H5.c) generating this sequence:


    /*
     * Terminate each interface. The termination functions return a positive
     * value if they do something that might affect some other interface in a
     * way that would necessitate some cleanup work in the other interface.
     */
#define DOWN(F)                                                               
    (((n = H5##F##_term_interface()) && (at + 8) < sizeof loop)?              
     (sprintf(loop + at, "%s%s", (at ? "," : ""), #F),                        
      at += HDstrlen(loop + at),                                              
      n):                                                                    

     ((n > 0 && (at + 5) < sizeof loop) ?                                     
     (sprintf(loop + at, "..."),                                              
      at += HDstrlen(loop + at),                                              
     n) : n))

    do {
        pending = 0;
        /* Try to organize these so the "higher" level components get shut
         * down before "lower" level components that they might rely on. -QAK
         */
        pending += DOWN(R);
        pending += DOWN(D);
        pending += DOWN(L);
        pending += DOWN(G);
        pending += DOWN(A);
        pending += DOWN(S);
        pending += DOWN(T);
        /* Don't shut down the file code until objects in files are shut down
*/
        if(pending == 0)
            pending += DOWN(F);

        /* Don't shut down "low-level" components until "high-level"
components
         * have successfully shut down.  This prevents property lists and IDs
         * from being closed "out from underneath" of the high-level objects
         * that depend on them. -QAK
         */
        if(pending == 0) {
            pending += DOWN(AC);
            pending += DOWN(Z);
            pending += DOWN(FD);
            pending += DOWN(P);
            pending += DOWN(PL);
            /* Don't shut down the error code until other APIs which use it
are shut down */
            if(pending == 0)
                pending += DOWN(E);
            /* Don't shut down the ID code until other APIs which use them are
shut down */
            if(pending == 0)
                pending += DOWN(I);
            /* Don't shut down the skip list code until everything that uses
it is down */
            if(pending == 0)
                pending += DOWN(SL);
            /* Don't shut down the free list code until _everything_ else is
down */
            if(pending == 0)
                pending += DOWN(FL);
        }
    } while(pending && ntries++ < 100);


Basically, this loop attempts to shutdown higher level interfaces, then
midlevel interfaces, then low level interfaces.  I assume the low level
interfaces are used by the higher level interface.  Therefore, those can't be
shut down until the higher level interfaces have successfully disassociated
all APIs.

It looks as though the library is getting hung up on trying to shutdown the
Error Code support.  Here is the H5E_term_interface routine:


int
H5E_term_interface(void)
{
    int n = 0;

    FUNC_ENTER_NOAPI_NOINIT_NOERR

    if(H5_interface_initialize_g) {
        int ncls, nmsg, nstk;

        /* Check if there are any open error stacks, classes or messages */
        ncls = H5I_nmembers(H5I_ERROR_CLASS);
        nmsg = H5I_nmembers(H5I_ERROR_MSG);
        nstk = H5I_nmembers(H5I_ERROR_STACK);

        n = ncls + nmsg + nstk;
        if(n > 0) {
            /* Clear any outstanding error stacks */
            if(nstk > 0)
                H5I_clear_type(H5I_ERROR_STACK, FALSE, FALSE);

            /* Clear all the error classes */
            if(ncls > 0) {
                H5I_clear_type(H5I_ERROR_CLASS, FALSE, FALSE);

                /* Reset the HDF5 error class, if its been closed */
                if(H5I_nmembers(H5I_ERROR_CLASS) == 0)
                    H5E_ERR_CLS_g = -1;
            } /* end if */

            /* Clear all the error messages */
            if(nmsg > 0) {
                H5I_clear_type(H5I_ERROR_MSG, FALSE, FALSE);

                /* Reset the HDF5 error messages, if they've been closed */
                if(H5I_nmembers(H5I_ERROR_MSG) == 0) {
                    /* Include the automatically generated error code
termination */
                    #include "H5Eterm.h"
                } /* end if */
            } /* end if */
        } /* end if */
        else {
            /* Destroy the error class, message, and stack id groups */
            H5I_dec_type_ref(H5I_ERROR_STACK);
            H5I_dec_type_ref(H5I_ERROR_CLASS);
            H5I_dec_type_ref(H5I_ERROR_MSG);

            /* Mark closed */
            H5_interface_initialize_g = 0;
            n = 1; /*H5I*/
        } /* end else */
    } /* end if */

    FUNC_LEAVE_NOAPI(n)
} /* end H5E_term_interface() */


Well, there are three elements to error handling that could be coming back
always positive, i.e., n = ncls + nmsg + nstk > 0.

I'll make a wild guess: imagine that something in this process fails to happen
correctly.  Then, stack is cleared, messages are cleared, classes are
cleared...all fine and dandy.  Then it has to go through the loop again and
tries again n = ncls + nmsg + nstk.  If an error happens the the error stack
(or one of the other two) is now non-empty.  Basically, I'm wondering if HD5
can get past this stage at all if it keeps generating an error for some
reason.

Anyway, can anyone think of something in the packages that is creating or not
creating an HD5 error message, different from what might have been done in the
past?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37713>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]