Re: debugs from an interesting CBDATA case study

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?

Amos
Received on Tue Jan 21 2014 - 08:23:27 MST