On 01/21/2014 01:23 AM, Amos Jeffries wrote:
On 14/01/2014 3:31 p.m., Alex Rousskov wrote:
On 01/07/2014 08:35 AM, Alex Rousskov wrote:
2) [Add cbdata debugging to] find which object stores the invalid cbdata
pointer. Then find how that invalid pointer gets to that object.
I think it
On 14/01/2014 3:31 p.m., Alex Rousskov wrote:
On 01/07/2014 08:35 AM, Alex Rousskov wrote:
2) [Add cbdata debugging to] find which object stores the invalid cbdata
pointer. Then find how that invalid pointer gets to that object.
I think it happens here:
#8 0x0834f190 in
On 01/07/2014 08:35 AM, Alex Rousskov wrote:
2) [Add cbdata debugging to] find which object stores the invalid cbdata
pointer. Then find how that invalid pointer gets to that object.
I think it happens here:
#8 0x0834f190 in CommCbMemFunT (aMeth=
(void
For background:
CBDATA uses an external lock counting and pointer management structure
to perform auto_ptr/unique_ptr semantics on objects. If the objects
this pointer does not match a magic binary pattern in the CBDATA
object (cookie) for the class it will assert as shown below.
For the code
On 01/07/2014 02:40 AM, Amos Jeffries wrote:
For background:
CBDATA uses an external lock counting and pointer management structure
to perform auto_ptr/unique_ptr semantics on objects. If the objects
this pointer does not match a magic binary pattern in the CBDATA
object (cookie) for the
