locked
Resolving Assert failure before Main execution RRS feed

  • Question

  • //MyClass.cpp
    MyClass accessClass;
    
    MyClass::MyClass()
    {
        loopRuning = true;   //type bool
        deviceHandle = NULL; //type unsigned long
        //ResetDevice();     //temporarily commented out to assist in debuging
        opMode = -1;         // type int
        targetMsg = -1;      //type int
        hasDevice = false;   //type bool
        isRunning = false;   //type bool
        msgFound = false;    //type bool
    
        msgCount = 0;        //type WORD (unsigned short)
    }

    The assertion failure occurs after MyClass constructor exits before line 1 of int main(array<System::String ^> ^args) is ever called. No pointers or arrays appear to be initialized, called, or referenced up to this point.

    _ASSERTE(_CrtIsValidHeapPointer(pUserData))

    @ _msize_dbg(void *pUserData, int nBlockUse) in dbgheap.c

    @ _dllonexit_nolock(int (void)* func, void (void)*** pbegin, void (void)*** pend) in onexit.c

    @ __dllonexit(int (void)* func, void (void)*** pbegin, void (void)*** pend) in onexit.c

    @ _onexit(int (void)* func) in atonexit.c

    @ atexit(void (void)* func) in atonexit

    @ 'dynamic initializer for 'myClass''() in myClass.cpp

    @ _initterm(void** pfbegin, void pfend) in pureMSILcode.cpp

    @ <CrtImplementationDetails>::LanguageSupport::InitializeNative() in mstartup.cpp

    @ (eventually) languageSupport.Initialize() in mstartup.cpp

    Any ideas on what is going on or where I should be looking? The usual suggestion is look for heap access failure, but the words 'new' or 'malloc' do not appear anywhere in my code.

    Tuesday, August 6, 2013 9:50 PM

Answers

  • Huh, my coworkers technique of comment everything out worked.

    The problem was the deconstructor. Don't ask me why.

    As soon as '~MyClass()' and 'MyClass::~MyClass(){...}' got commented out the assert error went away.

    I had hopped to package all the code needed to reset the usbDevice into a deconstructor for auto-execution on close, but it looks like I'll need to tie that to an On_FormClosing event instead.

    • Marked as answer by PsiDog Wednesday, August 7, 2013 3:01 PM
    Wednesday, August 7, 2013 3:01 PM

All replies

  • Any ideas on what is going on or where I should be looking?

    You have not shown the complete class definition. Presumably there are member objects
    which get created whenever the class is instantiated. We need to see them as well.

    >deviceHandle = NULL; //type unsigned long

    Note that the NULL macro is conventionally reserved for use with pointers.
    Using it to set a non-pointer object can send a confusing message to readers
    of the code.

    I take it from the main signature that you've posted that this is a C++/CLI
    or WinForms program. Always state what kind of application you're building,
    and which compiler and version you're using.

    - Wayne


    Wednesday, August 7, 2013 1:59 AM
  • //MyClass.h
    
    //#include "UsbDriver.h"
    //#include "Constants.h"
    #define WORD unsigned short
    
    class SimaSide
    {
    public:
        MyClass();
        ~MyClass();
        bool SetMode(bool isConnected, int mode);                       //Start, Stop, or change USB device operating mode
        bool ClearMsg(int msgNum);                                      //Cancel a msg set to Tx
        bool SetTxMsg(int msgNum, WORD * wspList, WORD numWsps);        //Create a msg for Tx
        bool RequestRx(int msgNum);                                     //Flag a msg for monitoring
        bool GetMsg(WORD *wspBuffer, WORD *numWSPs);      //True if last Rx request was filled
        bool StartLoop( void);
        bool HasDevice() { return hasDevice;};
        bool IsRunning() { return isRunning;};
    
        
    private:
        int opMode;
        int targetMsg;
        bool ResetDevice();
        bool InitializeRx();
        bool InitializeCnt(bool set); //set if true, unset if false
        bool hasDevice;
        bool isRunning;
        bool msgFound;
        /*
        bool loopRuning;
        unsigned long deviceHandle;
        WORD wspCount;
        WORD indexBlk[0x40];
        WORD wspBank[78];*/
    };
    
    extern MyClass accessClass;

    Wayne, this is indeed a C++/CLI WinForm project.  The original program was written using DIALOGEX resources in Visual Studio 6, but I gambled that a complete rewrite from scratch using a more modern GUI will be just as slow as updating the old stuff but easier to maintain in the future. Everything was going to smoothly to plan, until the Assert error.

    This program has 2 classes: a MainForm class using managed code, and MyClass to cover the unmanaged access calls to UsbDevice.h. As such, while the overall project is set to use /CLR, myClass.cpp was uniquely toggled to use no common language runtime support.

    My last successful run was after I finished the WinForm GUI when MyClass was mostly an empty shell.

    I'm currently in the middle of the ancient debuging method of commenting everything added since then out until the error goes away. That's why some .h lines are currently commented out. At this point I have commented out the interior of every MyClass.cpp function leaving only a 'return false;' So far the error still hasn't gone away yet.

    @Pavel A: I tried that. _msixe_dbg is called three times internally with a heap pointer to something like 0x00xxxxx, each within 0xFF of the previous. Then on on the 4th call the stack references my class's constructor with a pointer value of 0x0Exxxxx. I haven't had any luck narrowing down the issue that way.




    • Edited by PsiDog Wednesday, August 7, 2013 2:07 PM
    Wednesday, August 7, 2013 2:04 PM
  • Huh, my coworkers technique of comment everything out worked.

    The problem was the deconstructor. Don't ask me why.

    As soon as '~MyClass()' and 'MyClass::~MyClass(){...}' got commented out the assert error went away.

    I had hopped to package all the code needed to reset the usbDevice into a deconstructor for auto-execution on close, but it looks like I'll need to tie that to an On_FormClosing event instead.

    • Marked as answer by PsiDog Wednesday, August 7, 2013 3:01 PM
    Wednesday, August 7, 2013 3:01 PM
  • The problem was the deconstructor. Don't ask me why.

    As soon as '~MyClass()' and 'MyClass::~MyClass(){...}' got commented out the assert error went away.

    I had hopped to package all the code needed to reset the usbDevice into a deconstructor ...

    Again, you have't shown the code for either the ctor or the dtor.
    So we can't offer any explanation for the observed behavior.

    A guess would be that you are trying to use a class member after that member has been
    destroyed. Or perhaps mismatching new/delete and new[]/delete[], etc. I'm quite sure
    there's a reasonable explanation.

    - Wayne

    Wednesday, August 7, 2013 5:03 PM
  • Again, you have't shown the code for either the ctor or the dtor.

    So we can't offer any explanation for the observed behavior.

    The class constructor was shown in post #1. 

    As mentioned in post #4 all functions had been commented down to shells. If I was ambiguous, that included the constructor/ deconstructor too. Like so:

    //MyClass.cpp
    #include "MyClass.h"
    
    MyClass accessClass;
    
    MyClass::MyClass()
    {
        /*
        loopRuning = true;
        deviceHandle = 0;
        ResetDevice();
        opMode = -1;
        targetMsg = -1;
        isRunning = false;
        msgFound = false;
        wspCount = 0;
        */
    }
    
    MyClass::~MyClass()
    {
        /*
        loopRuning = false;
        Sleep(10);
        if(hasDevice)
        {
            closeAllBoards();
            hasDevice = false;
        }
        */
    }
    
    bool MyClass::EveryFunction()
    {
        /*
        //Code
        */
        return false;
    }

    MyClass was declared as a global instance. Maybe in a CRL application a globally declared class instance can not have a deconstructor, and my attempt to include one was causing it to self destruct in the middle of heap allocation. Or something.

    Anyway, one way or another my problem was resolved. At this point further explanation for the phenomenon would only be useful for other users with the same problem or as an aid for a similar future project.

    Wednesday, August 7, 2013 6:07 PM