memory access violation with std::list

Discussion in 'C++' started by Kyle Teague, Nov 26, 2003.

  1. Kyle Teague

    Kyle Teague Guest

    I have a list of pointers to structs as a private member of a class.
    If I call begin() in the same function as I added the data then no
    access violation occurs. However, if I try to call begin() in a member
    function of the same class I get a memory access violation.

    For example:

    // this is fine, no error
    void CBase::FuncA( void ) {
    plugin_info_t *plugin_info = new plugin_info_t;
    plugin_info->pPluginSend = ProcPluginSend;
    plugin_info->pGetUserList = 0;
    lstPlugins.push_back(plugin_info);

    list<plugin_info_t*>::iterator i;
    i = lstPlugins.begin();
    }

    // this causes an access violation
    void CBase::FuncB( void ) {
    list<plugin_info_t*>::iterator i;
    i = lstPlugins.begin();
    }
     
    Kyle Teague, Nov 26, 2003
    #1
    1. Advertising

  2. Kyle Teague

    David White Guest

    "Kyle Teague" <> wrote in message
    news:...
    > I have a list of pointers to structs as a private member of a class.
    > If I call begin() in the same function as I added the data then no
    > access violation occurs. However, if I try to call begin() in a member
    > function of the same class I get a memory access violation.
    >
    > For example:
    >
    > // this is fine, no error


    Possibly fine, but not necessarily. The lack of an adverse reaction does not
    always mean that all is well.

    > void CBase::FuncA( void ) {


    No need for 'C' on your class names.
    http://www.jelovic.com/articles/stupid_naming.htm

    > plugin_info_t *plugin_info = new plugin_info_t;
    > plugin_info->pPluginSend = ProcPluginSend;
    > plugin_info->pGetUserList = 0;
    > lstPlugins.push_back(plugin_info);
    >
    > list<plugin_info_t*>::iterator i;
    > i = lstPlugins.begin();
    > }



    > // this causes an access violation
    > void CBase::FuncB( void ) {
    > list<plugin_info_t*>::iterator i;
    > i = lstPlugins.begin();
    > }


    There's nothing obviously wrong. You'll need to give us the definition of
    class CBase and the code that creates the CBase object and calls these
    members. The symptom suggests that the CBase object is invalid (e.g., been
    destroyed) at the time you call FuncB(), because a call to the list's
    begin() should not crash, whether you have added any items to the list or
    not.

    DW
     
    David White, Nov 26, 2003
    #2
    1. Advertising

  3. Kyle Teague

    Kyle Teague Guest

    "David White" <> wrote in message news:<XpUwb.2616$>...
    > "Kyle Teague" <> wrote in message
    > news:...
    > > I have a list of pointers to structs as a private member of a class.
    > > If I call begin() in the same function as I added the data then no
    > > access violation occurs. However, if I try to call begin() in a member
    > > function of the same class I get a memory access violation.
    > >
    > > For example:
    > >
    > > // this is fine, no error

    >
    > Possibly fine, but not necessarily. The lack of an adverse reaction does not
    > always mean that all is well.
    >
    > > void CBase::FuncA( void ) {

    >
    > No need for 'C' on your class names.
    > http://www.jelovic.com/articles/stupid_naming.htm
    >
    > > plugin_info_t *plugin_info = new plugin_info_t;
    > > plugin_info->pPluginSend = ProcPluginSend;
    > > plugin_info->pGetUserList = 0;
    > > lstPlugins.push_back(plugin_info);
    > >
    > > list<plugin_info_t*>::iterator i;
    > > i = lstPlugins.begin();
    > > }

    >
    >
    > > // this causes an access violation
    > > void CBase::FuncB( void ) {
    > > list<plugin_info_t*>::iterator i;
    > > i = lstPlugins.begin();
    > > }

    >
    > There's nothing obviously wrong. You'll need to give us the definition of
    > class CBase and the code that creates the CBase object and calls these
    > members. The symptom suggests that the CBase object is invalid (e.g., been
    > destroyed) at the time you call FuncB(), because a call to the list's
    > begin() should not crash, whether you have added any items to the list or
    > not.
    >
    > DW


    My actual class was not named CBase, sorry for the confusion. By the
    way, it crashes for ALL the lists at the same point. I've included
    what was needed for the class, it

    struct plugin_info_t;
    struct user_info_t;

    typedef int (* PluginMainProc)(UINT event, WPARAM wParam, LPARAM
    lParam);
    typedef std::list<user_info_t*>& (* GetUserListProc)();
    typedef int (* GetBattleSocketProc)();
    typedef LRESULT (* PluginSendProc)(UINT id, WPARAM wParam, LPARAM
    lParam);
    typedef BOOL (* BattleIncomingProc)(BYTE id, WORD length, LPVOID
    data);
    typedef BOOL (* MessageIncomingProc)(DWORD id, DWORD ping, DWORD
    flags, LPSTR name, LPSTR text);

    struct plugin_info_t
    {
    DWORD cVersion;
    char cTitle[256];

    PluginSendProc pPluginSend;
    GetUserListProc pGetUserList;

    BattleIncomingProc cBattleIncoming;
    MessageIncomingProc cMessageIncoming;
    };

    struct user_info_t {
    char name[64];
    char statstring[512];
    unsigned long flags;
    unsigned long ping;
    };

    using namespace std;

    LRESULT ProcPluginSend(UINT id, WPARAM wParam, LPARAM lParam);

    class PluginHandler
    {
    string plugdir;
    list<HMODULE> lstInstances;
    list<FARPROC> lstProcs;
    list<plugin_info_t*> lstPlugins;
    public:
    PluginHandler(char *dir);
    ~PluginHandler();
    void GetPlugins();
    int LoadPlugin(char *file);

    void SendBNCSData(DWORD id, DWORD ping, DWORD uflags, LPSTR name,
    LPSTR text);

    };

    PluginHandler::pluginHandler(char *dir)
    {
    plugdir = dir;
    }

    //crashes here
    PluginHandler::~PluginHandler()
    {
    list<plugin_info_t*>::iterator i;
    for(i=lstPlugins.begin(); i!=lstPlugins.end(); i++)
    delete *i;

    list<HMODULE>::iterator j;
    for(j=lstInstances.begin(); j!=lstInstances.end(); j++)
    FreeLibrary(*j);
    }

    void PluginHandler::GetPlugins()
    {
    WIN32_FIND_DATA FindFileData;
    HANDLE hFind;
    char *path = new char[plugdir.size() + 3];
    strcpy(path, plugdir.c_str());
    strcat(path, "\\*");
    hFind=FindFirstFile(path, &FindFileData);

    do {
    if( FindFileData.dwFileAttributes == 0x20) {
    char *p = FindFileData.cFileName;

    // is this a dll? if it is, load it
    if (!strnicmp(p + strlen(p) - 4, ".dll", 4))
    LoadPlugin(p);
    }
    } while ( FindNextFile(hFind, &FindFileData) );

    FindClose(hFind);
    delete [] path;
    }

    //crashes here too
    void PluginHandler::SendBNCSData(DWORD id, DWORD ping, DWORD uflags,
    LPSTR name, LPSTR text)
    {
    list<plugin_info_t*>::iterator i;
    i = lstPlugins.begin();
    }

    LRESULT ProcPluginSend(UINT id, WPARAM wParam, LPARAM lParam)
    {
    /*switch(id) {
    case ZBF_APPENDTEXT:
    cout << (char *)lParam << endl;
    //control->_richedit.AppendText((COLORREF)wParam, (char *)lParam);
    return 0;
    case ZBF_TIMESTAMP:
    cout << "[TIMESTAMP] ";
    return 0;
    case ZBF_SENDTEXT:
    pBot->SendText((char *)lParam);
    //BnetSend((char *)lParam);
    //control->_sendtext.Clear();
    return 0;
    } */

    return -1;
    }
     
    Kyle Teague, Nov 26, 2003
    #3
  4. Kyle Teague

    David White Guest

    "Kyle Teague" <> wrote in message
    news:...
    > My actual class was not named CBase, sorry for the confusion. By the
    > way, it crashes for ALL the lists at the same point. I've included
    > what was needed for the class, it
    >
    > struct plugin_info_t;
    > struct user_info_t;
    >
    > typedef int (* PluginMainProc)(UINT event, WPARAM wParam, LPARAM
    > lParam);
    > typedef std::list<user_info_t*>& (* GetUserListProc)();
    > typedef int (* GetBattleSocketProc)();
    > typedef LRESULT (* PluginSendProc)(UINT id, WPARAM wParam, LPARAM
    > lParam);
    > typedef BOOL (* BattleIncomingProc)(BYTE id, WORD length, LPVOID
    > data);
    > typedef BOOL (* MessageIncomingProc)(DWORD id, DWORD ping, DWORD
    > flags, LPSTR name, LPSTR text);
    >
    > struct plugin_info_t
    > {
    > DWORD cVersion;
    > char cTitle[256];
    >
    > PluginSendProc pPluginSend;
    > GetUserListProc pGetUserList;
    >
    > BattleIncomingProc cBattleIncoming;
    > MessageIncomingProc cMessageIncoming;
    > };
    >
    > struct user_info_t {
    > char name[64];
    > char statstring[512];
    > unsigned long flags;
    > unsigned long ping;
    > };
    >
    > using namespace std;
    >
    > LRESULT ProcPluginSend(UINT id, WPARAM wParam, LPARAM lParam);
    >
    > class PluginHandler
    > {
    > string plugdir;
    > list<HMODULE> lstInstances;
    > list<FARPROC> lstProcs;
    > list<plugin_info_t*> lstPlugins;
    > public:
    > PluginHandler(char *dir);
    > ~PluginHandler();
    > void GetPlugins();
    > int LoadPlugin(char *file);
    >
    > void SendBNCSData(DWORD id, DWORD ping, DWORD uflags, LPSTR name,
    > LPSTR text);
    >
    > };
    >
    > PluginHandler::pluginHandler(char *dir)
    > {
    > plugdir = dir;
    > }
    >
    > //crashes here
    > PluginHandler::~PluginHandler()
    > {
    > list<plugin_info_t*>::iterator i;
    > for(i=lstPlugins.begin(); i!=lstPlugins.end(); i++)
    > delete *i;
    >
    > list<HMODULE>::iterator j;
    > for(j=lstInstances.begin(); j!=lstInstances.end(); j++)
    > FreeLibrary(*j);
    > }
    >
    > void PluginHandler::GetPlugins()
    > {
    > WIN32_FIND_DATA FindFileData;
    > HANDLE hFind;
    > char *path = new char[plugdir.size() + 3];
    > strcpy(path, plugdir.c_str());
    > strcat(path, "\\*");
    > hFind=FindFirstFile(path, &FindFileData);
    >
    > do {
    > if( FindFileData.dwFileAttributes == 0x20) {
    > char *p = FindFileData.cFileName;
    >
    > // is this a dll? if it is, load it
    > if (!strnicmp(p + strlen(p) - 4, ".dll", 4))
    > LoadPlugin(p);
    > }
    > } while ( FindNextFile(hFind, &FindFileData) );
    >
    > FindClose(hFind);
    > delete [] path;
    > }
    >
    > //crashes here too
    > void PluginHandler::SendBNCSData(DWORD id, DWORD ping, DWORD uflags,
    > LPSTR name, LPSTR text)
    > {
    > list<plugin_info_t*>::iterator i;
    > i = lstPlugins.begin();
    > }


    Given the plethora of types used, and the fact that this is obviously part
    of a much bigger application, I can't determine the cause of the problem
    from this code. However, I'm sure that the reason your program is crashing
    is that the PluginHandler object has been destroyed or corrupted. In the
    above function and in the destructor, the list is the first member you are
    accessing and begin() is the first member function of it that you are
    calling. If the 'this' pointer passed to a member function doesn't point to
    a valid object, then the program will likely crash when you try to access
    any member. The crash is merely a symptom of another problem that occurred
    earlier. I suggest that you use a debugger to trace your program and see
    what's going on, or add a whole lot of debug code to display various values
    at various points to find out where the PluginHandler is becoming corrupted.

    Note that this NG covers standard C++ only. It could be that your problem is
    caused by not using the MS Windows API correctly, in which case you will get
    a lot more help at a Windows programming newsgroup, such as
    comp.os.ms-windows.programmer.win32.

    DW
     
    David White, Nov 26, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bengt Richter

    time.mktime memory access violation bug

    Bengt Richter, Nov 18, 2003, in forum: Python
    Replies:
    6
    Views:
    742
    Bengt Richter
    Nov 21, 2003
  2. Bit byte

    Memory (read) access violation handling in C

    Bit byte, Jun 18, 2006, in forum: C Programming
    Replies:
    4
    Views:
    641
    Dave Thompson
    Jun 26, 2006
  3. aling
    Replies:
    12
    Views:
    570
    Greg Comeau
    Nov 15, 2005
  4. Replies:
    3
    Views:
    1,126
  5. Replies:
    1
    Views:
    417
    Daniel T.
    Oct 28, 2006
Loading...

Share This Page