Access Violation CwinThread::CreateThread

ForNow

Hi, I am using the 2 step process CWinThread constructer and CreateThread to Create a UI thread and I am getting a Access Violation somewhere in CWinThread::CreateThread From the debugger I can already see that the thread has been created as the thread id from DEBUG->threads matches m_nThreadID The address where the access violation occurs matches the pointer to my derived CWinThread pointer threadptr[I}

threadptr[i] = NULL;
threadptr[i] = new SockCLeintThread(start_port);

     if (threadptr\[i\] == NULL)
            m\_pMainWnd->MessageBox((LPCTSTR)"SockClientThreadFail",NULL,MB\_ICONERROR);

          threadptr\[i\]->CreateThread(CREATE\_SUSPENDED,0,NULL);

Lost User

I have no idea whether this is connected but you should not be casting an ASCII string to a LPCTSTR; the two may not be the same. Use the _T() macro to ensure your strings are generated to the correct mode for the project.

Use the best guess

ForNow

fixed that up however that statement was never executed I inserted this test

ASSERT(threadptr[i]->IsKindOf(RUNTIME_CLASS(SockCLeintThread));

Lost User

Which means what?

Use the best guess

ForNow

Richard I don't know why I cleaned up my laptop and all of the sudden my code doesn't work anyway a couple of points After I create my CFramewnd and do a Showwindow it doesn't have a window handle its nulls The Thread after creating the object

CWinThread->wm_pActiveWnd and CWinThread->m_pMainWnd

are both NULL I populated via the debugger and CreateThread worked

Erudite_Eric

Does your thread func start off by calling that AFX_MANAGE_STATE macro (or whatever it is called)? MFC threads need to do thkis else they screw up like this with all sorts of exceptions.

ForNow

I populate both the Main and active window of the thread With my CFrameWnd * an that seemed to do the trick Thanks

Stephen Hewitt

ForNow wrote:

m_pMainWnd->MessageBox((LPCTSTR)"SockClientThreadFail",NULL,MB_ICONERROR);

Look at the underlined section. What are you hoping to achieve by the cast? If you're compiling for non-Unicode it does nothing and if it's a Unicode build it tells the compiler not to issue an error but to shut up and assume the ANSI string is a Unicode one, which it's clearly not. Best case scenario is a garbled string in the message box, worst case an access violation because of no double NULL terminator. This is the typical fate of the cast-happy: turning a compile-time error into a runtime one. Don't cast if you don't know what's going on or fumble around casting to suppress a compiler error. You don't need any casts:

m_pMainWnd->MessageBox(_T("SockClientThreadFail"), NULL, MB_ICONERROR);

Steve

Joe Woodbury

I believe AFX_MANAGE_STATE is only needed when exporting certain functions from a DLL which use MFC and load DLL resources.

Erudite_Eric

I am sure I have had to use it in threads in MFC apps. Its been a while and of course it use could be required in many situations.

pasztorpisti

On which thread do you encounter the access violation? Can you post the piece of code that causes the crash? It would be nice to see the whole code of your worker thread and the codepieces from he main thread that are used in the communication with the worker (like thread creation, receiving messages from the worker). As "UI thread" I usually name the thread that drives a gui framework, by default in MFC this is the main thread. In my opinion its better to use just one thread to handle the GUI (the main thread with MFC) because that is perfectly enough on every platform with any GUI framework despite the fact that on windows any threads are allowed to create their own set of windows but this is not a good practice. As I see your thread handles networking, how do you send/receive data? In case of multithreading a very nice strategy is minimizing the amount of shared data as much as possible usually by using message posting. Sometimes the amount of shared data can be reduced to zero along with the bugs. Post some code if possible and then we can give advices. EDIT: Forgot to mention that in MFC there are two different kind of threads: UI threads that support message pumping for the UI and simple worker threads. There are two AfxBeginThread() functions and one of them creates a UI thread while the other creates a worker. You can simply go by creating a worker thread with a lightweight wrapper class around this worker AfxBeginThread() call. Deriving from CWinThread and using its CreateThread method is useful only if you want to reuse the same thread object to execute and exit many threads on it but reusing the same thread object twice is a bad design anyway because it introduces a lot of bugs. Its better to recreate thread objects. If you want to preserve state between thread executions then put the preservable state into a separate object and pass the same state object to every time you recreate the thread after the destruction of the previous thread. Often its better simply keep the thread running than terminating it and then starting another (but in my frameworks I always use pools and precreated threads, the frameworks hides the creation/destruction of threads and that is cool).