Re: debugs from an interesting CBDATA case study

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 happens here:
>>
>>
>>>> #8 0x0834f190 in CommCbMemFunT (aMeth=
>>>> (void (Comm::TcpReceiver::*)(Comm::TcpReceiver * const, const
>>>> CommCbMemFunT<Comm::TcpReceiver, CommCloseCbParams>::Params &))
>>>> 0x834e270 <Comm::TcpReceiver::tcpConnectionClosed(CommCloseCbParams
>>>> const&)>, aJob=..., this=0xbffff268) at ../../../src/CommCalls.h:180
>>
>>
>> where we are passing a raw job pointer (job.get()) to CommCloseCbParams
>> object which then uses it as cbdata in CommCommonCbParams constructor:
>>
>>> CommCbMemFunT(const CbcPointer<C> &job, Method meth): JobDialer<C>(job),
>>> CommDialerParamsT<Params_>(job.get()),
>>
>>> CommCloseCbParams(void *aData);
>>
>>> CommCommonCbParams::CommCommonCbParams(void *aData):
>>> data(cbdataReference(aData)), ...
>>
>>
>> Does the attached untested patch help?

> Perfectly. Thank you!!!
>
> I have applied your fix to the branch with your details. Would you care
> to do the honours for trunk please?

Committed to trunk as r13250.

Thank you,

Alex.
Received on Tue Jan 28 2014 - 19:30:29 MST