Re: Can CWinThread::SuspendThread suspend yourself?

From:

"Alexander Grigoriev" <alegr@earthlink.net>

Newsgroups:

microsoft.public.vc.mfc,microsoft.public.win32.programmer.kernel

Date:

Thu, 8 Mar 2007 17:05:29 -0800

Message-ID:

<#m$ZJceYHHA.4368@TK2MSFTNGP06.phx.gbl>

When the thread starts to run, AfxBeginThread may not return yet and T may
not be assigned.

You need to use AfxGetThread() (?) or create the thread suspended (which is
a good idea anyway).

"Norman Diamond" <ndiamond@community.nospam> wrote in message
news:%23knV8LeYHHA.3824@TK2MSFTNGP02.phx.gbl...

I'm not sure if this is a generic coding bug (e.g. buffer overflow
somewhere), a violation of a Win32 constraint on SuspendThread, a
violation of an MFC constraint on CWinThread::SuspendThread, or a bug in
Visual Studio 2005's version of MFC or in Windows XP or where.

CWinThread *T = AfxBeginThread(f, p);

UINT f(LPVOID p) {
// do some stuff
T->SuspendThread();
// when someone resumes us, we continue
}

Running in debug mode under control of Visual Studio 2005, about 66% of
the time this runs silently, but about 33% of the time it gets an
exception on an assert in afxwin2.inl, which makes no sense to me. It
seems that m_hThread is non-NULL as it should be, and the assert complains
that a memory read failed at a highly suspicious memory address. The
memory address varies but is always a very small multiple of 4, looking
very suspiciously like a handle value not a memory address, making me
wonder who's trying to read memory there.

While typing this message I observed that __cdecl is missing from the
declaration of f. But Visual Studio 2005 didn't issue any error message
about the call to AfxBeginThread. I don't think I know the real problem
yet.