ASSERT_VALID fails with illegal vtable pointer
Paul Pettigrew -- chilli@aljan.com.au
Tuesday, March 18, 1997
Environment: VC++ 4.2b, NT 4.0 or Win 95
Multi-threaded app development.
I am receiving the above assertion when I ASSERT_VALID() on a CObject
derived pointer, that I obtain from ANY COblist access function.
The COblist is a member of a class that is instantiated in the main thread,
and this class contains a worker thread function that also accesses the COblist.
How can I make the CObject derived objects that I insert into the list thread-safe?
Where can I find information on "vtable pointers"?
Many thanks for your time,
Paul Pettigrew
Director,
Hot Chilli Software (Aust) Pty Ltd
chilli@aljan.com.au
Dan Kirby -- dkirby@accessone.com
Thursday, March 20, 1997
[Mini-digest: 2 responses]
Hi Paul,
You must avoid one thread writing to the list at the same time another
thread may be reading or writing to the list. MFC doesn't do any work to
provide thread-safe access to the list. You will have to use your own
synchronization objects (i.e. CCriticalSection) to protect access to the
list.
There are 2 possibilities for an incorrect v-table pointer: 1) the object
got corrupted, 2) the pointer to the object is incorrect. The latter is
most likely the case.
Look at your call stack after you get the assert and see where the
ASSERT_VALID() is being called. Normally you'll see ASSERT_VALID(this).
But how can 'this' be an incorrect address? Remember that the this pointer
is passed in on the stack. If something is overwriting the stack, you'll
have a bogus 'this' pointer. Or, when you perform a call like
"pObj->SomeFuncWithAssert()", the pointer pObj may be bogus. If pObj is
returned for the CObList, you may be getting a bogus value back or you may
have put a bogus value in.
Hopes this helps.
--dan
----------
> From: Paul Pettigrew
> To: 'MFC ListServ Help'
> Subject: ASSERT_VALID fails with illegal vtable pointer
> Date: Tuesday, March 18, 1997 2:17 AM
>
> Environment: VC++ 4.2b, NT 4.0 or Win 95
> Multi-threaded app development.
>
> I am receiving the above assertion when I ASSERT_VALID() on a CObject
> derived pointer, that I obtain from ANY COblist access function.
>
> The COblist is a member of a class that is instantiated in the main
thread,
> and this class contains a worker thread function that also accesses the
COblist.
>
> How can I make the CObject derived objects that I insert into the list
thread-safe?
> Where can I find information on "vtable pointers"?
>
> Many thanks for your time,
> Paul Pettigrew
> Director,
> Hot Chilli Software (Aust) Pty Ltd
> chilli@aljan.com.au
>
-----From: Paul Pettigrew
Thankyou Dan,
I will attempt to write a thread-safe CObList derived class, that uses =
CCriticalSection and CSingleLock.
Even with this guaranteeing that collision access will not occur, as you =
say pointers are on the stack...does this mean that if I create a new =
object in one thread and add it's pointer to the list, then when the =
other thread accesses this pointer, it will be garbage???
--
Paul Pettigrew
chilli@aljan.com.au
-----Original Message-----
From: Dan Kirby [SMTP:dkirby@accessone.com]
Sent: Friday, 21 March 1997 5:35 PM
To: mfc-l@netcom.com; chilli@aljan.com.au
Subject: Re: ASSERT_VALID fails with illegal vtable pointer
Hi Paul,
You must avoid one thread writing to the list at the same time another
thread may be reading or writing to the list. MFC doesn't do any work to
provide thread-safe access to the list. You will have to use your own
synchronization objects (i.e. CCriticalSection) to protect access to the
list.
There are 2 possibilities for an incorrect v-table pointer: 1) the =
object
got corrupted, 2) the pointer to the object is incorrect. The latter is
most likely the case. =20
Look at your call stack after you get the assert and see where the
ASSERT_VALID() is being called. Normally you'll see ASSERT_VALID(this). =
But how can 'this' be an incorrect address? Remember that the this =
pointer
is passed in on the stack. If something is overwriting the stack, =
you'll
have a bogus 'this' pointer. Or, when you perform a call like
"pObj->SomeFuncWithAssert()", the pointer pObj may be bogus. If pObj is
returned for the CObList, you may be getting a bogus value back or you =
may
have put a bogus value in.
Hopes this helps.
--dan
----------
> From: Paul Pettigrew
> To: 'MFC ListServ Help'
> Subject: ASSERT_VALID fails with illegal vtable pointer
> Date: Tuesday, March 18, 1997 2:17 AM
>=20
> Environment: VC++ 4.2b, NT 4.0 or Win 95
> Multi-threaded app development.
>=20
> I am receiving the above assertion when I ASSERT_VALID() on a CObject=20
> derived pointer, that I obtain from ANY COblist access function.
>=20
> The COblist is a member of a class that is instantiated in the main
thread,=20
> and this class contains a worker thread function that also accesses =
the
COblist.
>=20
> How can I make the CObject derived objects that I insert into the list
thread-safe?
> Where can I find information on "vtable pointers"?
>=20
> Many thanks for your time,
> Paul Pettigrew
> Director,
> Hot Chilli Software (Aust) Pty Ltd
> chilli@aljan.com.au
>=20
Sreekant Sreedharan -- sreekant@india.deneb.com
Tuesday, March 25, 1997
Hi Dan,
Dan Kirby wrote:
>
> [Mini-digest: 2 responses]
>
> Hi Paul,
>
> You must avoid one thread writing to the list at the same time another
> thread may be reading or writing to the list. MFC doesn't do any work to
> provide thread-safe access to the list. You will have to use your own
> synchronization objects (i.e. CCriticalSection) to protect access to the
> list.
>
> There are 2 possibilities for an incorrect v-table pointer: 1) the object
> got corrupted, 2) the pointer to the object is incorrect. The latter is
> most likely the case.
>
> Look at your call stack after you get the assert and see where the
> ASSERT_VALID() is being called. Normally you'll see ASSERT_VALID(this).
> But how can 'this' be an incorrect address? Remember that the this pointer
> is passed in on the stack. If something is overwriting the stack, you'll
> have a bogus 'this' pointer. Or, when you perform a call like
> "pObj->SomeFuncWithAssert()", the pointer pObj may be bogus. If pObj is
> returned for the CObList, you may be getting a bogus value back or you may
> have put a bogus value in.
>
> Hopes this helps.
>
> --dan
>
I'm not too sure, but I think MFC uses thread local storage to keep
track of the objects created. In such a case I think the ASSERT_VALID
macro may fail even though the pointer is valid because it is within the
same address space.
Do tell me if I an wrong.
--
- From Sreekant Sreedharan
Become an MFC-L member
| Вернуться в корень Архива
|