C / C++ / MFC

30-Apr-12 16:54

Well I figured out how to test my compiled output, and find most of the errors.

This is the heart of most of my program failures, and strange behavior. It has something to do with Threads.

On one example, I have a dialog box, that loads parameters. I then click OK, and run the validator, first creating a thread, and the validator runs in the thread, which produces strange errors, like not connecting to sql server.

If I dump the thread, and just run the code function, it works fine, no problem. So I have to decide whether to dump the threads, or try to fix them.

I've tried WaitForSingleObject, and now the MsgWaitForMultipleObjects. On the latter, it just crashes on check return code, in which I run a MessageBox, and crashes.

I am posting this to see if perhaps it just needs improvement. It crashes on Case 1:, but I'm not sure if it really has a problem there or not. The message is Access violation reading location 0x2102fe2b. I don't have the expertise to proceed with the message.

DWORD dwRet;
do {
dwRet = ::MsgWaitForMultipleObjects( 1, &hThread, FALSE, INFINITE, QS_ALLEVENTS );

if (dwRet != WAIT_OBJECT_0)
			{
     MSG msg;
     while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
     {
		TranslateMessage(&msg);
		DispatchMessage(&msg);
     }
}
} while ((dwRet != WAIT_OBJECT_0) && (dwRet != WAIT_FAILED));

DWORD dwExitCode = 0;		
if ( GetExitCodeThread( hThread, &dwExitCode ) ) {
		
	CloseHandle( hThread );
			
	switch ( dwExitCode ) {
		case 0:
		// Create Project Validate was Successful
		bReturn = TRUE;
		break;

		case -1:
		{
		SetFocus( ddl_ProjectCreate_DatabaseName_Field );
		SendMessage( ddl_ProjectCreate_DatabaseName_Field, CB_SETCURSEL, (WPARAM) 0, (LPARAM) 0 ); 
		}
		break;

		case 1:
		// Project type selection error
		MessageBox( g_hWndMainFrame, TEXT("You must select a project type to create\0"), TEXT("Create Project\0"), MB_OK );
		SetFocus( lv_ProjectCreate_ProjectType );
		break;

Code-o-mat1-May-12 0:29

Code-o-mat

1-May-12 0:29

What does your secondary thread do? Show some code if possible. On a sidenote, you mentioned setting strange errors from the thread like not connecting to sql, do you use COM for this? You might need to initialize COM with CoInitializeEx[^] in every thread that does some COM operations (i remember running into this once), did you do this?

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<

jkirkerx1-May-12 6:57

1-May-12 6:57

I wrote a post last week about my program working fine when running in debug F5, but the compiled version has many errors. So I've been running the compiled debug version, and using the just in time feature to locate errors. I fixed most of the errors, but the thread eludes me.

I'm using ODBC to connect to the sql server.

The dialog box runs 1 thread to validate when you press OK, and then the next thread to create the project, in which it copies files to the folder, sets permissions, creates a database and tables, users, permissions, write to the registry, and then opens the project.

The strange behavior on the SQL, is that the first sql function runs correctly, and then the 2nd one won't connect.

This is the sql function

BOOL bResult = FALSE;
	
SQLHENV henv;
SQLHDBC hdbc;
SQLHSTMT hstmt;
SQLRETURN retcode;

SQLWCHAR OutConnStr[1024];
SQLSMALLINT OutConnStrLen;

HWND desktopHandle = GetDesktopWindow();   // desktop's window handle

SQLWCHAR	szDatabaseExist[80];
SQLLEN		cbDatabaseExist = 0;
	
// Allocate environment handle
retcode = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv);

// Set the ODBC version environment attribute
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
	retcode = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER*)SQL_OV_ODBC3, 0); 

	// Allocate connection handle
	if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
		retcode = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc); 

		// Set login timeout to 5 seconds
		if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
				SQLSetConnectAttr(hdbc, SQL_LOGIN_TIMEOUT, (SQLPOINTER)5, 0);

			// Process data
			WCHAR pzSQLDriver[128];
			swprintf_s(pzSQLDriver, 128,
				L"Driver={SQL Server Native Client 10.0}; Server=%s; Database=master; Trusted_Connection=Yes;",
				pzServerName
			);				

			// Intialize Connection
			retcode = SQLDriverConnect( hdbc, desktopHandle, (SQLWCHAR*)pzSQLDriver,
				wcslen(pzSQLDriver), OutConnStr, 1024, &OutConnStrLen, SQL_DRIVER_NOPROMPT );

			// Allocate statement handle
			if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {               
				retcode = SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt); 

				// Process data
				WCHAR pzSQLCommand[512];
				swprintf_s(pzSQLCommand, 512,
					L"SELECT CASE WHEN db_id('%s') IS NOT NULL THEN 'TRUE' ELSE 'FALSE' END",
						pzDatabaseName
				);
				pzSQLCommand[wcslen(pzSQLCommand) + 1] = L'\0';
		
				retcode = SQLExecDirect( hstmt, (SQLWCHAR*)pzSQLCommand, SQL_NTS );				
					
				if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {						
						
					SQLBindCol( hstmt, 1, SQL_C_WCHAR, szDatabaseExist, sizeof(szDatabaseExist), &cbDatabaseExist );

					WCHAR *szResult = new WCHAR[cbDatabaseExist];

					while ((retcode = SQLFetch( hstmt )) != SQL_NO_DATA) {
						 swprintf_s(szResult, cbDatabaseExist, L"%s\n", szDatabaseExist );
						 szResult[wcslen(szResult)+1] = L'\0';
						}

					SQLFreeHandle(SQL_HANDLE_STMT, hstmt);						

					if( wcsncmp( szResult, L"TRUE", wcslen(szResult) ) > 0) {
						bResult = TRUE;
					}
					else {
						bResult = FALSE;
					}
						
				}
				SQLDisconnect(hdbc);
			}
                        SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
         }
    }
	
    SQLFreeHandle(SQL_HANDLE_ENV, henv);
}
   	
return bResult;

And then this a a preview of the contents that the thread runs for validation. If something doesn't jive, then the exitcode is generated, and returned to the thread creator, in which the thread creator generates a messagebox, and alters the dialog box.

    BOOL    bValidate = TRUE;
    BOOL    bResult = FALSE;
    DWORD   dwExitCode  = 0;
    DWORD   dwWebsitePath_Check = 0;
    DWORD   dwProjectName = 0;
    DWORD   dwFolderPath = 0;
    DWORD   dwDomainName = 0;
    DWORD   dwLicenseKey = 0;

    DWORD   dwServerName = 0;
    DWORD   dwDatabaseName = 0;
    DWORD   dwAuthMethod = 0;
    DWORD   dwAccountName = 0;
    DWORD   dwPassword = 0;

    WCHAR   *szValidKey = NULL;
    WCHAR   *szWebsitePath_Check = NULL;

    WCHAR   pzProjectType[ 64 ];
    WCHAR   pzProjectName[ MAX_PATH ];
    WCHAR   pzProjectPath[ MAX_PATH ];
    WCHAR   pzFolderPath[ MAX_PATH ];
    WCHAR   pzDomainName[ 255 ];
    WCHAR   pzLicenseKey[ 255 ];

    WCHAR   pzServerName[80];
    WCHAR   pzDatabaseName[80];
    WCHAR   pzAuthMethod[80];
    WCHAR   pzAccountName[80];
    WCHAR   pzPassword[80];

    PMAIN_RUNPROCESS pzValidate;
    pzValidate = (PMAIN_RUNPROCESS)lpParam;
    HWND cWnd               = pzValidate->m_cWnd;
    HWND hWndDlg            = pzValidate->m_hWndDlg;
    HWND lblStatusMessage   = pzValidate->m_StatusMessage;
    HWND pbProgressBar      = pzValidate->m_ProgressBar;

    PROJECT_TYPE projectType;

    // Load the Registry Class
    CA_Registry caReg;

    /////////////////////////////////////////////////////////////////////////////////////////////
// Project Type Validation

    DWORD   dwProjectType = 0;
    dwProjectType = ListView_GetNextItem( lv_ProjectCreate_ProjectType, -1, LVNI_FOCUSED );
    if ( dwProjectType == -1 ) {
        // No Selection has been made - Handle the Error in the Thread Creator
        return 1;
    }
    else {
        // A Selection has been made
        ListView_GetItemText( lv_ProjectCreate_ProjectType, dwProjectType, 0, pzProjectType, 60 );
        if ( wcsncmp( pzProjectType, L"North American Standard Edition 2012", wcslen( L"North American Standard Edition 2012" ) ) == 0 ) {
            projectType = NASE2012_STANDARD;
        }
    }

// End of Project Type Validation    /////////////////////////////////////////////////////////////////////////////////////////////
// Does the Database Exist
	BOOL bDatabaseExist = FALSE;

	CA_SQLServer_ODBC caODBC;
	bDatabaseExist = caODBC._does_SQLServer_Database_Exist_hWnd( pzServerName, pzDatabaseName );

	if ( bDatabaseExist ) {
		return 13;	
	}

	// End of Database Exist	
	/////////////////////////////////////////////////////////////////////////////////////////////
	// if SQL Authentication, validate the credentials
	BOOL bSQLValidate = FALSE;
		
	if ( !bSQL ) {
		// Validate using Windows Authentication
		bSQLValidate = caODBC._validate_SQLServer_Credentials_WinAuth( pzServerName );
		
		if ( !bSQLValidate ) {
			bValidate = FALSE;
			return 11;
		}

	}
	else {
		// Validate using SQL Authentication
		bSQLValidate = caODBC._validate_SQLServer_Credentials_SQLAuth( pzServerName, pzAccountName, pzPassword );
		
		if ( !bSQLValidate ) {
			bValidate = FALSE;
			return 12;
		}

	}
	
// End of Check Project Name
/////////////////////////////////////////////////////////////////////////////////////////////

     return dwExitCode;

Albert Holguin1-May-12 3:46

1-May-12 3:46

jkirkerx wrote:
Access violation reading location 0x2102fe2b

What this is telling you is that you're trying to access memory that has either been deallocated already or it is stack memory that belongs to another thread. What variable is in that address? Where and how was it allocated? That should lead you to the cause of your problem.

jkirkerx1-May-12 6:59

1-May-12 6:59

I need a quick lesson on that. If I can find out what is there, I can fix my errors faster and be on my way.

Albert Holguin2-May-12 5:35

I've traced it down to this

2-May-12 5:35

Whenever the error comes up, you can break execution then go to the call stack and trace your path backwards to see where (within your code, not the framework) the error occurred. If you have a memory address such as this, you can look at the variables involved in the call that gave you the error and see which one has that address, that will tell you which one caused it (although it's still up to you to figure out why the error occurred).

jkirkerx1-May-12 13:55

1-May-12 13:55

I've traced my issues down to the parameters that I'm passing to the thread. I must of implemented it wrong, and left it in memory. I thought it clears automatically when the thread exits.

So this is on the CreateThread Side of the Function, and of course I read the parameters back on the Thread side.

Question:

do I have to clean up here manually, or is it automatic?

// Create a common memory space for threads
PMAIN_RUNPROCESS pzUpdateProcess;
pzUpdateProcess = ( PMAIN_RUNPROCESS ) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof( PMAIN_RUNPROCESS ));

// Now copy the pointers over to the heap
pzUpdateProcess->m_hWndDlg = _updates_Dialog_hWnd;
pzUpdateProcess->m_StatusMessage = lbl_Update_Dialog_StatusMessage_Label;
pzUpdateProcess->m_ProgressBar = pb_Update_Dialog_ProgressBar_Field;

// CreateThread for running Process
hThread = (HANDLE)CreateThread(
    &sa,
    0,
    &_updates_Dialog_CreateProcess_Thread,
    pzUpdateProcess,
    0,
    &dwThreadID
);

The Code Analyst is complaining about a DPAC (ACL) or something below. Is it really needed for proper operation?

SECURITY_ATTRIBUTES sa;
    sa.bInheritHandle = TRUE;
    sa.lpSecurityDescriptor = NULL;
    sa.lpSecurityDescriptor = (PSECURITY_DESCRIPTOR) malloc(SECURITY_DESCRIPTOR_MIN_LENGTH);
    InitializeSecurityDescriptor(sa.lpSecurityDescriptor, SECURITY_DESCRIPTOR_REVISION);
    
    // The Code Analyst is complaining about dPAC I think where the null is, 
    SetSecurityDescriptorDacl(sa.lpSecurityDescriptor, TRUE, (PACL) ->NULL<-, FALSE);</b>

    sa.nLength = sizeof(sa);
    sa.bInheritHandle = TRUE;
    sa.nLength=sizeof(SECURITY_ATTRIBUTES);

Solved Now

jkirkerx1-May-12 17:35

1-May-12 17:35

I didn't size it correctly, and found I had to use HeapFree to clean the memory after the thread returns.

Wow, now it works, and strange behavior went away.

PMAIN_RUNPROCESS pzValidate;
pzValidate = ( PMAIN_RUNPROCESS ) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof( MAIN_RUNPROCESS ));

// Free the Heap Memory 
HeapFree( GetProcessHeap(), 0, pzValidate );
pzValidate = NULL;

Re: Solved Now

Albert Holguin1-May-12 18:22

1-May-12 18:22

By default, anything you manually create on the heap, you must manually free. Thread will only deallocate its own stack memory.

Re: Solved Now

jkirkerx1-May-12 18:33

1-May-12 18:33

I'm learning Albert. It just never dawned on me that's what the holdup was on all the other problems I had with the dialog boxes, and sql server connections.

Now I can go back and use the advice and suggestions given to me over the last week.

Thanks for listening, I appreciate it.

Re: Solved Now

Albert Holguin2-May-12 5:36