HP.com home

Compaq C++ User Documentation

 

Compaq C++

Compaq C++
Using Compaq C++ for Tru64 UNIX and Linux Alpha


Previous Contents Index


Appendix C
Third Degree Messages

This appendix describes Third Degree messages generated by the C++ Class and Standard Libraries. None of the following messages contribute to memory corruption in programs or cause memory depletion in long running applications.

  1. Third degree 576 byte leak and 16 byte leak messages from __init_cxx_exc
    When you instrument a Compaq C++ program with Third degree, the tool might generate 576 byte leak and 16 byte leak messages like the following from the Class Library routine __init_cxx_exe :


    576 bytes in 1 leak created at: 
        malloc                         libc.so 
        pc = 0x3ff81d35c04             libcxx.so 
        pc = 0x3ff81d35e20             libcxx.so 
        __init_cxx_exc                 libcxx.so 
     
    16 bytes in 1 leak (including 1 super leak) created at: 
        malloc                         libc.so 
        pc = 0x3ff81d35c04             libcxx.so 
        pc = 0x3ff81d35ca4             libcxx.so 
        pc = 0x3ff81d35dfc             libcxx.so 
        __init_cxx_exc                 libcxx.so 
    

    A program like the following would generate the previous messages:


    int main () {return 0;} 
    

    These two leaks are generated by the C++ exception handling code. This storage is memory allocated to process exception handling during program startup and is deleted by the operating system when the program exits. Third degree reports a leak because the operating system, rather than C++ code, deletes the storage. The operating system deletes this storage for these reasons:
    • The compiler does not slow down exit for all C++ programs.
    • After the program terminates, the compiler verifies that no additional C++ exceptions need handling.
  2. Third degree 8/24/48 byte leak messages from __init_cxx_exc
    When you instrument a Compaq C++ program with Third degree, the tool might generate four 8, four 24, and four 48 byte leak messages like the following from the Class Library routine __init_cxx_exe :


    48 bytes in 1 leak created at: 
        malloc                         libc.so 
        __cma_tis_mutex_create         libc.so 
        AllocateInternalMutex(void)    libcxx.so 
        Mutex::Mutex(void)             libcxx.so 
        Iostream_init::initialize(void) libcxx.so 
        Iostream_init::Iostream_init(void) libcxx.so 
        __init_cxxl_init142DB80C       libcxx.so 
     
    24 bytes in 1 leak created at: 
        operator new(unsigned long)    libcxx.so 
        AllocateInternalMutex(void)    libcxx.so 
        Mutex::Mutex(void)             libcxx.so 
        Iostream_init::initialize(void) libcxx.so 
        Iostream_init::Iostream_init(void) libcxx.so 
        __init_cxxl_init142DB80C       libcxx.so 
     
    8 bytes in 1 leak (including 1 super leak) created at: 
        operator new(unsigned long)    libcxx.so 
        Iostream_init::initialize(void) libcxx.so 
        Iostream_init::Iostream_init(void) libcxx.so 
        __init_cxxl_init142DB80C       libcxx.so 
    

    A program like the following would generate the previous messages:


    int main () {return 0;} 
    

    The messages originate from the creation of Class Library Iostream mutexes for cin , cout , clog , and cerr , which are created at program startup. The operating system cleans up the memory rather than deleting it at program exit from C++.
  3. Additional Third degree 48/24 byte leak messages from __init_cxx_exc
    When you instrument a Compaq C++ program with Third degree, the tool might generate an additional 24 and 48 byte leak messages like the following from the Class Library routine __init_cxx_exe :


    48 bytes in 1 leak created at: 
        malloc                         libc.so 
        __cma_tis_mutex_create         libc.so 
        AllocateInternalMutex(void)    libcxx.so 
        Mutex::Mutex(void)             libcxx.so 
        Iostream_init::Iostream_init(void) libcxx.so 
        __init_cxxl_init142DB80C       libcxx.so 
     
    24 bytes in 1 leak created at: 
        operator new(unsigned long)    libcxx.so 
        AllocateInternalMutex(void)    libcxx.so 
        Mutex::Mutex(void)             libcxx.so 
        Iostream_init::Iostream_init(void) libcxx.so 
        __init_cxxl_init142DB80C       libcxx.so 
    

    A program like the following would generate the previous messages:


    int main () {return 0;} 
    

    The messages also come from a mutex used in Iostream locking; they are created at program startup and are cleaned up by the operating system rather than being deleting at program exit by C++.
  4. Third degree 48 byte leak messages from __init_cxxl_initxxxxxxxx
    When you instrument a Compaq C++ program with Third degree, the tool might generate an additional 48 byte leak message like the following from the Class Library routine __init_cxxl_initxxxxxxxx :


    48 bytes in 1 leak (including 1 super leak) created at: 
        malloc                         libc.so 
        __cma_tis_mutex_create         libc.so 
        pc = 0x3ff81d3a46c             libcxx.so 
        __cma_tis_once                 libc.so 
        __cxx_test_and_set_atomic      libcxx.so 
        __init_cxxl_init142DB80C       libcxx.so 
    

    A program like the following would generate the previous message:


    int main () {return 0;} 
    

    This message comes from the mutex used to initialize the Class Library; the mutex is created at program startup and is deleted by the operating system rather than by C++ code at program exit.
  5. Third degree fon warning message from __init_cxx_exe
    When you instrument a C++ program with Third degree, the tool might generate a fon warning like the following from the C++ Class Library routine __init_cxx_exe :


    ------------------------------------------------ fon -- 0 -- 
    calling free(0) 
        free                           fon 
        pc = 0x120068090               fon 
        __init_cxx_exc                 fon 
     
    -------------------------------------------------------------- 
    

    A program like the following would generate the previous message:


    int main () {return 0;} 
    

    The message, freeing a NULL pointer, is only a warning. In this case, the library does in fact free a NULL pointer, but this is valid behavior. You can ignore the message.
  6. Third degree wis error from __vec_new_eh
    When you instrument a C++ program with Third degree, the tool might generate a wis error like the following from the C++ Standard Library routine __vec_new_eh :


    ------------------------------------------------ wis -- 1 -- 
    wis.cxx: 5: writing invalid stack at byte 64 of 64 in frame of 
    array_new_general 
    (void*, int, unsigned long, void*, void (*)(void*, int), void* 
    (*)(unsigned long), 
    void (*)(void*), int, int, unsigned int) 
    array_new_general(void*, int, unsigned long, void*, void (*)(void*, 
    int), void* 
    (*)(unsigned long), void (*)(void*), int, int, unsigned int) 
                                       wis 
        __vec_new_eh                   wis 
     
    -------------------------------------------------------------- 
    

    A program like the following would generate the previous message:


    struct C {C() {};}; 
    int main () { 
        C* pc = new C[5]; 
        delete []pc; 
        return 0; 
        } 
    

    Programs using global array new can generate the message when Third degree encounters a special scheduling instruction. This false positive message has been reported to Third degree.
  7. Third degree rin error message
    The following error message is generated in programs that use exception handling in the Class Library. This false positive message has been reported to Third degree.


    rin.c: 7: reading invalid stack at byte 656 of 656 in frame of main 
        proc_at_0x12000e350            rin 
        __exc_virtual_unwind           rin 
        exc_virtual_unwind             rin 
        main                           rin, rin.c, line 7 
        __start                        rin 
    
  8. Third degree might report false positive uninitiated memory errors
    As of Atom 2.47, Third degree might report false positive uninitiated memory errors where variables of less than 32 bits are involved. Note that bool data types, which the Standard Library uses extensively, fall into this category.
    For example, when you instrument a C++ program with Third degree, the tool might generate a rus error with Atom version 2.47 in the STL map class. The error would be generated by a program like the following:


    #include <map> 
    main() { 
        map <int, int> the_test_map; 
        the_test_map[1] = 1; 
        the_test_map[2] = 2; 
    } 
    

    The following is an example of a small, self-contained program (reduced from the above program) that generates the same error.


    struct tree 
    { 
        bool       b; 
        void init () {;} 
        tree(const int i = 3, bool b = true) : b(b) 
        { 
          init(); 
        } 
    }; 
    void main() { 
         tree t; 
    } 
    


Index Contents
About PDF files: The PDF files on this site can be read online or printed using Adobe® Acrobat® Reader. If you do not have this software on your system, you may download it from Adobe's website.
Privacy statement Using this site means you accept its terms C++ support
© 2008 Hewlett-Packard Development Company, L.P.