Print

Print


Hi Gerardo,

On Thu, 16 Sep 2004, Gerardo Ganis wrote:

>
>
>    Hi Matthias,
>
>    Unfortunately I am not able to reproduce this occurence by myself
>
> **********************
>
> In netx/src/TXNetConn.cxx:
>
> ==9343== 48 bytes in 2 blocks are definitely lost in loss record 360 of 563
> ==9343== at 0x4002BD79: __builtin_new (vg_replace_malloc.c:172)
> ==9343== by 0x63C19B4D: TXPhyConnection::BuildXMessage(ESendRecvOptions, bool,
> bool) (in
> /afs/slac.stanford.edu/package/cernroot/vol21/cvs040908_1418/Linux24RH72_i386_gcc2953/lib/libNetx.so)
> ==9343== by 0x63C10789: TXConnectionMgr::ReadMsg(short, ESendRecvOptions) (in
> /afs/slac.stanford.edu/package/cernroot/vol21/cvs040908_1418/Linux24RH72_i386_gcc2953/lib/libNetx.so)
> ==9343== by 0x63C1360E: TXNetConn::ReadPartialAnswer(XReqErrorType &, unsigned
> int &, ClientRequest *, bool, void **, TXNetConn::EThreeStateReadHandler &) (in
> /afs/slac.stanford.edu/package/cernroot/vol21/cvs040908_1418/Linux24RH72_i386_gcc2953/lib/libNetx.so)
> ==9343== by 0x63C12737: TXNetConn::ClientServerCmd(ClientRequest *, void const
> *, void **, void *, bool) (in
> /afs/slac.stanford.edu/package/cernroot/vol21/cvs040908_1418/Linux24RH72_i386_gcc2953/lib/libNetx.so)
> ==9343== by 0x63C12868: TXNetConn::SendGenCommand(ClientRequest *, void const *,
> void **, void *, bool, char *, ServerResponseHeader *) (in
> /afs/slac.stanford.edu/package/cernroot/vol21/cvs040908_1418/Linux24RH72_i386_gcc2953/lib/libNetx.so)
>
>
> **************************
>
>     Is this something new to the ROOT version or was it there also with
>     XTNetFile (this part of the code was basically unchanged) ?
>

I did not check if it's there if I use XTNetFile instead of TXNetFile.
I'll see if I can find out in the next hour (I'll have to leave then for
today).

 Matthias

>
> >The SafeDelete(cmdrespMex) in SendGenCommand does not always do its job, or
> > it's not always reached.
>
>     Yes, it must be something like that, but by looking at the code it is not
>     obvious to see why the cleanup should not always be complete ... It must be
>     some tricky situation.
>
>     Fabrizio: any idea?
>
>     Cheers, Gerri
>