Random crashes? huh?

I can't seem to find out why my code is crashing randomly.
I've got 2 projects in VC++ 2005.
One builds a DLL which just exports some functions that take a pointer to a struct and return unsigned int. Right now all they do is print out all the data in the struct to a file.

The other project is a console app that loads the DLL & calls whatever function I want in the DLL. I have a text menu with options to Load/Unload the DLL, and call each function...

Sometimes when I press 'L' to load the DLL it says it fails to load the DLL, but most times it loads fine.
Sometimes when I press a number to call an exported function it will crash (even the catch(...) handlers don't help), but other times the function runs just fine.

Sometimes is crashes the very first time I run a function, and other times I can run the same function 10 times before it crashes.

How the hell do I debug this mess? :confused:
What are the most likely causes of this type of random crashing behavior? Stack corruption or something?

EDIT: I also get a bunch of "TestHarness.exe has triggered a breakpoint" messages, but if I break there it just drops me somewhere deep inside the CRT code.

I think we might need an example. The fact it may load or not load the DLL is a little odd imo. There appears to be something fundamentally wrong with your situation, possibly something basic.

Here are some random thoughts about random crashes :-) Check for any or all of the following:

- uninitialized pointer
- double deleting a pointer
- buffer overrun
- issues with order of initialization of statics
- shallow copy when you wanted deep copy

I think I've narrowed it down to the code that causes the crash, but I still don't see what's wrong.

Code:

---

Tstring
ToStr( DWORD  num )
{
        std::basic_stringstream<TCHAR> ss;
        ss << num;
        Tstring ret;
        ss >> ret;
        return ret;
}


void
FillArgList( std::vector<Tstring>&  argList,
                        EXIT_DSECT*  dsect )
{
        try
        {
                argList.push_back( _T( "EXIT_NUMBER:" ) );
                Tstring strTemp = ToStr( dsect->EXIT_NUMBER );
                argList.push_back( strTemp );
                argList.push_back( _T( "EXIT_INIT_COMPUTER_NAME:" ) );
                argList.push_back( dsect->EXIT_INIT_COMPUTER_NAME );
...
        }
        catch( std::bad_alloc&  e )
        {
                std::cout << "Caugt a bad_alloc!  " << e.what() << std::endl;
        }
        catch( ... )
        {
                std::cout << "Caugt an unhandled exception!" << std::endl;
        }
}

---

If I comment out the lines in red it doesn't crash.
Tstring is a typedef for std::basic_string<TCHAR>

Although, even when I comment out the lines above, I still catch bad_alloc exceptions randomly, but it doesn't crash.

Can FillArgList() ever be called with dsect being set to NULL?

Quote:

---

Originally Posted by MacGyver

Can FillArgList() ever be called with dsect being set to NULL?

---

That's my thought. dsect is null or pointing somewhere unexpected.

Quote:

---

Originally Posted by MacGyver

Can FillArgList() ever be called with dsect being set to NULL?

---

No, I always pass the address of a local struct. I don't do any memory allocation of my own.
It would blow up on one of the lines below the commented out lines if that was the case.

The dsect struct has TCHAR strings and DWORD numbers in it. Only the lines where I call ToStr() on the DWORDS are what blows up (sometimes).

OK, I've refined the crash even farther. If I leave the other lines uncommented but comment out these lines (in red) it gives me the occasional bad_alloc, but no crash:

Code:

---

Tstring
ToStr( DWORD  num )
{
        std::basic_stringstream<TCHAR> ss;
        ss << num;
        Tstring ret;
        ss >> ret;
        return ret;
}

---

I've tried building in UNICODE and ASCII and get the same problems either way.
The value of num is the same. I keep calling it with the same value and most times it works, sometimes it throws bad_alloc, and other times it crashes.

I think the crash happens just after the FillArgList() function returns.

BTW, the dsect local variable is created in the .exe and its address is passed to the DLL function where the code above lives.

it's hard to say without seeing more code, but most of the problems I've seen are caused by either binary incompatibility or mismatched calling conventions. in the first case just remember to always specify a byte padding boundary for structures and avoid interfacing with non-pod types (ie: std::string, et al) like the plague. in the second case (which isn't really an issue unless you're using GetProcAddress) just be careful that the function pointer is defined with the same calling convention as the library routine.

Quote:

---

Originally Posted by Sebastiani

it's hard to say without seeing more code, but most of the problems I've seen are caused by either binary incompatibility or mismatched calling conventions. in the first case just remember to always specify a byte padding boundary for structures and avoid interfacing with non-pod types (ie: std::string, et al) like the plague. in the second case (which isn't really an issue unless you're using GetProcAddress) just be careful that the function pointer is defined with the same calling convention as the library routine.

---

Actually, I am using GetProcAddress(). Should I be using something else instead?

In .exe:

Code:

---

unsigned int
RunXINIT( HMODULE hDLL )
{
        try
        {
                pXINIT pFunc = (pXINIT)GetProcAddress( hDLL, "XINIT" );

                if ( pFunc == NULL )
                {
                        PrintError( "Error running XINIT()!" );
                        return 0;
                }

                EXIT_INITTERM_DSECT dsect;
                GetEXIT_INITTERM_DSECT( dsect );  // Populate dsect with some data.
                return (pFunc)( &dsect );  // Calls XINIT() in the DLL.
        }
        catch( ... )
        {
                cout << "Caught an unhandled exception!" << endl;
                PrintMsg( " " );
                return 0;
        }
}

---

In DLL:

unsigned int

Code:

---

XINIT( EXIT_INITTERM_DSECT*  dsect )
{
        try
        {
                TRACE( "*** XINIT() ***" );

                if ( dsect == NULL )
                {
                        return 1;
                }

                unsigned int rc = EXIT_SUCCESS;
                std::vector<Tstring> argList;

                argList.push_back( _T( "==============================  XINIT()  ==============================" ) );
                FillArgList( argList, dsect );

                CUExit::CallScript( argList );  // Calls system() with a .bat file & all args concatenated together.
                return rc;
        }
        catch( std::bad_alloc&  e )
        {
                std::cout << "Caught a bad_alloc in XINIT()!" << e.what() << std::endl;
        }
        catch( ... )
        {
                std::cout << "Caught an unhandled exception in XINIT()!" << std::endl;
                getch();
        }

        return 1;
}

---

If it's not valid for dsect to be NULL then it should be passed by reference instead.

What is a Tstring? Is that something you made yourself? If so, my money's on the problem being in that.

"caught" is spelt with an h

Code:

---

EXIT_INITTERM_DSECT dsect;
GetEXIT_INITTERM_DSECT( dsect );  // Populate dsect with some data.

---

I'm guessing dsect is being passed by reference here or it's really a macro of some sort. Otherwise, this is kind of pointless.

Is pXINIT typedef'ed as this:

Code:

---

typedef unsigned int (*pXINIT)(EXIT_INITTERM_DSECT*);

---

Quote:

---

Originally Posted by iMalc

If it's not valid for dsect to be NULL then it should be passed by reference instead.

What is a Tstring? Is that something you made yourself? If so, my money's on the problem being in that.

"caught" is spelt with an h

---

The DLL functions are extern "C" functions, so that part has to pass by pointers.

Code:

---

typedef std::basic_string<TCHAR>        Tstring;

---

Quote:

---

Originally Posted by MacGyver

Code:

---

EXIT_INITTERM_DSECT dsect;
GetEXIT_INITTERM_DSECT( dsect );  // Populate dsect with some data.

---

I'm guessing dsect is being passed by reference here or it's really a macro of some sort. Otherwise, this is kind of pointless.

Is pXINIT typedef'ed as this:

Code:

---

typedef unsigned int (*pXINIT)(EXIT_INITTERM_DSECT*);

---

---

Yes, GetEXIT_INITTERM_DSECT() takes a reference to dsect, and that's the typedef I'm using for the DLL function pointer.

Code:

---

#ifdef _UNICODE
#  define Strncpy_s                wcsncpy_s
#else
#  define Strncpy_s                strncpy_s
#endif

void
GetEXIT_INITTERM_DSECT( EXIT_INITTERM_DSECT&  dsect )
{
        dsect.EXIT_EXIT_NUMBER                        = 1;
        Strncpy_s( dsect.EXIT_INIT_COMPUTER_NAME,        (sizeof(dsect.EXIT_INIT_COMPUTER_NAME) / sizeof(TCHAR)),
                _T("Computer_Name"),                        (sizeof(dsect.EXIT_INIT_COMPUTER_NAME) / sizeof(TCHAR)) );
        Strncpy_s( dsect.EXIT_MESSAGE,                        (sizeof(dsect.EXIT_MESSAGE) / sizeof(TCHAR)),
                _T("Message"),                                (sizeof(dsect.EXIT_MESSAGE) / sizeof(TCHAR)) );
        dsect.EXIT_RETURN_CODE                        = 2;
        dsect.EXIT_USER_FULLWORD                = 3;
        dsect.EXIT_VERSION                        = 4;
}

---

I'm thinking there must be a connection between the random crashes and the bad_alloc's being thrown... If I remove all the vector.push_back() calls I don't get any bad_alloc's anymore. I tried changing to const TCHAR* instead of Tstrings and allocating/deallocating memory myself, but I got a bad_alloc when trying to allocate just 11 bytes (then it works fine the next time...).

Another strange thing is that sometimes when LoadLibrary() fails I get "One or more arguments are invalid", and other times I get "A dynamic link library (DLL) initialization routine failed."

Sounds like something might be wrong with your strings then, although I don't see anything wrong off hand. For LoadLibrary() to fail arbitrarily, there's got to be something seriously wrong that you're missing.

I think I found the cause of the LoadLibrary() problems. If I comment out this line in DllMain(), it never fails to load:

Code:

---

BOOL APIENTRY
DllMain( HANDLE /*hModule*/,
                DWORD  ul_reason_for_call,
                LPVOID /*lpReserved*/
                )
{
        TRACE( "*** DllMain() ***" );

    switch (ul_reason_for_call)
        {
                case DLL_PROCESS_ATTACH:
                        TRACE( "DLL_PROCESS_ATTACH" );
//                        CUExit::ReadCfgFile();
                        break;
                case DLL_THREAD_ATTACH:
                        TRACE( "DLL_THREAD_ATTACH" );
                        break;
                case DLL_THREAD_DETACH:
                        TRACE( "DLL_THREAD_DETACH" );
                        break;
                case DLL_PROCESS_DETACH:
                        TRACE( "DLL_PROCESS_DETACH" );
                        break;
    }

        return TRUE;
}

bool
CUExit::ReadCfgFile()
{
        TRACE( "*** CUExit::ReadCfgFile() ***" );
        Tifstream fin( "UExit.cfg" );

        if ( !fin )
        {
                TRACE( "readCfgFile():  Failed to open file UExit.cfg!" );
                return false;
        }

        if ( !std::getline( fin, m_ScriptToCall ) )
        {
                TRACE( "readCfgFile():  getline() failed!" );
                return false;
        }

        TRACE( _T("readCfgFile():  m_ScriptToCall = '") + m_ScriptToCall + _T("'") );
        return true;
}

---

EDIT: Oh crap, I spoke too soon... :(

Are you allowed to do that kind of work in DLLMain()? I would expect so, but from this article I think you should just do the most basic initialization of variables:

http://msdn.microsoft.akadns.net/en-.../ms682583.aspx

Perhaps you should call that function in your DLL from your EXE.

You shouldn't take any locks in DllMain, and the streams often do internal locking, so it's risky.

Quote:

---

Originally Posted by CornedBee

You shouldn't take any locks in DllMain, and the streams often do internal locking, so it's risky.

---

OK, I moved it into a different place. Now DllMain() does nothing but return TRUE, but when I loop through several dozen LoadLibrary/FreeLibrary calls I get eventually get "Not enough storage is available to process this command." I put a 50ms sleep between LoadLibrary/FreeLibrary calls in case it was a timing issue, but that didn't help.

I also tried building new projects in VC++ 6.0 (using the same source files) and it's giving the same results.

Do you have any global or static objects in the DLL?

Quote:

---

Originally Posted by MacGyver

Do you have any global or static objects in the DLL?

---

Not anymore.
Although I'm still getting bad_alloc's and the "Not enough storage is available to process this command." LoadLibrary() errors after loading/unloading the DLL about 20-30 times.

These are the header files included in the DllMain file; I don't know if they have any objects in them that would cause any problems?

Code:

---

#include <windows.h>
#include <tchar.h>
#include <conio.h>        // DEBUG ONLY
#include <fstream>
#include <sstream>
#include <cstdio>                // For _spawnv() & _wspawnv().
#include <process.h>        // For _P_NOWAIT.

---

OK, I've stripped this down to the bare bones and LoadLibrary() still fails after 20-30 calls:

stdafx.h:

Code:

---

#if !defined(AFX_STDAFX_H__7B54890C_3655_4A2C_BA76_444CC4D20F7E__INCLUDED_)
#define AFX_STDAFX_H__7B54890C_3655_4A2C_BA76_444CC4D20F7E__INCLUDED_

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000

// Insert your headers here
#define WIN32_LEAN_AND_MEAN        // Exclude rarely-used stuff from Windows headers

#include <windows.h>
#include <tchar.h>

#endif // !defined(AFX_STDAFX_H__7B54890C_3655_4A2C_BA76_444CC4D20F7E__INCLUDED_)

---

UExit.h:

Code:

---

#ifndef UEXIT_H_INCLUDED_JULY_2_2008
#define UEXIT_H_INCLUDED_JULY_2_2008

#ifdef _XDLL
#  define UEXIT_API __declspec(dllexport)
#else
#  define UEXIT_API __declspec(dllimport)
#endif

#endif        // UEXIT_H_INCLUDED_JULY_2_2008

---

UExit.cpp:

Code:

---

#include "stdafx.h"
#include "UExit.h"

BOOL APIENTRY
DllMain( HANDLE /*hModule*/,
        DWORD  ul_reason_for_call,
        LPVOID /*lpReserved*/
        )
{
        switch (ul_reason_for_call)
        {
                case DLL_PROCESS_ATTACH:
                        break;
                case DLL_THREAD_ATTACH:
                        break;
                case DLL_THREAD_DETACH:
                        break;
                case DLL_PROCESS_DETACH:
                        break;
        }

        return TRUE;
}

---

TestHarness.cpp:

Code:

---

#include "stdafx.h"
#include <iostream>
#include <cstdlib>

using namespace std;


HMODULE
LoadDLL()
{
        HMODULE hDLL = LoadLibrary( _T("UExit.dll") );

        if ( hDLL == NULL )
        {
                cout << "Error loading DLL!" << endl;
                exit( 1 );
        }
        else
        {
                cout << "DLL Loaded successfully." << endl;
        }

        return hDLL;
}

void
UnloadDLL( HMODULE&  hDLL )
{
        if ( hDLL == NULL )
        {
                cout << "The DLL isn't loaded!" << endl;
        }
        else
        {
                if ( FreeLibrary( hDLL ) == FALSE )
                {
                        cout << "Error unloading DLL!" << endl;
                }
                else
                {
                        cout << "DLL unloaded successfully." << endl;
                        hDLL = NULL;
                }
        }
}

int main()
{
        HMODULE hDLL = NULL;

        for ( int i = 0; i < 1000; ++i )
        {
                cout << "*** " << i << endl;
                Sleep( 50 );
                hDLL = LoadDLL();
                Sleep( 50 );
                UnloadDLL( hDLL );
        }

        return 0;
}

---

How can THIS possibly be failing??? :confused:

Windows is broken? Have you googled for similar things?

Moral of the story: prefer static linking.

Minimal example (sans the no-op switch in DllMain) runs fine on my computer - currently at 400.

Quote:

---

Originally Posted by CornedBee

Minimal example (sans the no-op switch in DllMain) runs fine on my computer - currently at 400.

---

Which compiler?
Can you post the Compile & Link options? Maybe I've got something messed up there?
Here are my settings for the UExit.dll:

Code:

---

/O2 /GL /I "..\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "UNICODE" /D "_UNICODE" /D "_XDLL" /D "_WINDLL"
/FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W4 /WX /nologo /c /Zi /TP /errorReport:prompt


/OUT:"D:\Programming\C++\UExit\x86-vc8\Release\UExit.dll" /INCREMENTAL:NO /NOLOGO /DLL /MANIFEST /MANIFESTFILE:"Release\UExit.dll.intermediate.manifest"
/DEBUG /PDB:"d:\Programming\C++\UExit\x86-vc8\Release\UExit.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

---

and the Test Harness:

Code:

---

/O2 /GL /I "..\include" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "UNICODE" /D "_UNICODE" /D "_CRT_SECURE_NO_WARNINGS"
/FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W4 /WX /nologo /c /Zi /TP /errorReport:prompt


/OUT:"D:\Programming\C++\UExit\x86-vc8\Release\TestHarness.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"Release\TestHarness.exe.intermediate.manifest"
/DEBUG /PDB:"d:\Programming\C++\UExit\x86-vc8\Release\TestHarness.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /LTCG /MACHINE:X86 /ERRORREPORT:PROMPT
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

---

Sounds a bit like this: http://forums.msdn.microsoft.com/en/...-1398db52a6ba/

This thread's even better: http://www.gamedev.net/community/for...opic_id=440135

But I don't know if that answers your question or not . . . .

VC++.Net 2003, default empty Win32 DLL & Console app, debug build.

Quote:

---

Originally Posted by CornedBee

VC++.Net 2003, default empty Win32 DLL & Console app, debug build.

---

Sonofa..........! I just created a brand new DLL and Console project in VC++ 2008 express and compiled those files, and it ran with no problems whatsoever (although I used a newer compiler than at work and I'm running Vista instead of XP).

The only differences in compiler options are the addition of these switches: /Oi /Gy
and these Linker options: /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DYNAMICBASE /NXCOMPAT

EDIT: and then I removed those differences too and it still worked. I think this might be a good excuse for me to work at home from now on. ;)