Okay, I'll play with it some more.
Have a look at myclient.cc and myserver.cc in
lsst-dbdev1.ncsa.illinois.edu:~danielw/xssi/test
I put your public key in, so you should be able to login and have a look.
-Daniel
On 05/08/2014 10:15 PM, Andrew Hanushevsky wrote:
> Hi Daniel,
>
> I can't see anything wrong. So, you should put in the old print statements
> where you allocate and delete (also indicate how much you allocated). Then
> we can see if you are indeed doing what you think you are doing. I can do
> that as well if you give me the stuff that compiles and create the
> appropriate shared library.
>
> Andy
>
> On Thu, 8 May 2014, Daniel L. Wang wrote:
>
>> Hi Andy,
>>
>> I'm trying to make sure that I don't leak memory using the client interface,
>> but I still end up leaking about 100 bytes for each sequence of
>> getservice-provision-request-close-cleanup. I seem to be failing to release
>> memory in 2 places. Here's a valgrind report for 30 iterations of the
>> sequence.
>>
>> ==13424== 450 bytes in 30 blocks are definitely lost in loss record 7 of 8
>> ==13424== at 0x4A07152: operator new[](unsigned long)
>> (vg_replace_malloc.c:363)
>> ==13424== by 0x401C92: (anonymous
>> namespace)::MyRequest::MyRequest(XrdSsiSession*) (myclient.cc:30)
>> ==13424== by 0x402693: (anonymous namespace)::MyResource::makeRequest()
>> (myclient.cc:177)
>> ==13424== by 0x40263F: (anonymous
>> namespace)::MyResource::ProvisionDone(XrdSsiSession*) (myclient.cc:171)
>> ==13424== by 0x4C279C9:
>> XrdSsiSessReal::HandleResponse(XrdCl::XRootDStatus*, XrdCl::AnyObject*)
>> (XrdSsiSessReal.cc:157)
>> ==13424== by 0x4C26C69:
>> XrdCl::ResponseHandler::HandleResponseWithHosts(XrdCl::XRootDStatus*,
>> XrdCl::AnyObject*, std::vector<XrdCl::HostInfo,
>> std::allocator<XrdCl::HostInfo> >*) (XrdClXRootDResponses.hh:850)
>> ==13424== by 0x4F47693: (anonymous
>> namespace)::OpenHandler::HandleResponseWithHosts(XrdCl::XRootDStatus*,
>> XrdCl::AnyObject*, std::vector<XrdCl::HostInfo,
>> std::allocator<XrdCl::HostInfo> >*) (XrdClFileStateHandler.cc:86)
>> ==13424== by 0x4F3AEDF: XrdCl::XRootDMsgHandler::HandleResponse()
>> (XrdClXRootDMsgHandler.cc:1008)
>> ==13424== by 0x4F38204: XrdCl::XRootDMsgHandler::Process(XrdCl::Message*)
>> (XrdClXRootDMsgHandler.cc:300)
>> ==13424== by 0x4F198D1: XrdCl::Stream::HandleIncMsgJob::Run(void*)
>> (XrdClStream.hh:279)
>> ==13424== by 0x4F6FFED: XrdCl::JobManager::RunJobs()
>> (XrdClJobManager.cc:148)
>> ==13424== by 0x4F6FB37: RunRunnerThread (XrdClJobManager.cc:33)
>> ==13424==
>> ==13424== 3,360 bytes in 30 blocks are definitely lost in loss record 8 of 8
>> ==13424== at 0x4A075BC: operator new(unsigned long)
>> (vg_replace_malloc.c:298)
>> ==13424== by 0x4C27F8C: XrdSsiSessReal::ProcessRequest(XrdSsiRequest*,
>> unsigned short) (XrdSsiSessReal.cc:260)
>> ==13424== by 0x4026DC: (anonymous namespace)::MyResource::makeRequest()
>> (myclient.cc:179)
>> ==13424== by 0x40263F: (anonymous
>> namespace)::MyResource::ProvisionDone(XrdSsiSession*) (myclient.cc:171)
>> ==13424== by 0x4C279C9:
>> XrdSsiSessReal::HandleResponse(XrdCl::XRootDStatus*, XrdCl::AnyObject*)
>> (XrdSsiSessReal.cc:157)
>> ==13424== by 0x4C26C69:
>> XrdCl::ResponseHandler::HandleResponseWithHosts(XrdCl::XRootDStatus*,
>> XrdCl::AnyObject*, std::vector<XrdCl::HostInfo,
>> std::allocator<XrdCl::HostInfo> >*) (XrdClXRootDResponses.hh:850)
>> ==13424== by 0x4F47693: (anonymous
>> namespace)::OpenHandler::HandleResponseWithHosts(XrdCl::XRootDStatus*,
>> XrdCl::AnyObject*, std::vector<XrdCl::HostInfo,
>> std::allocator<XrdCl::HostInfo> >*) (XrdClFileStateHandler.cc:86)
>> ==13424== by 0x4F3AEDF: XrdCl::XRootDMsgHandler::HandleResponse()
>> (XrdClXRootDMsgHandler.cc:1008)
>> ==13424== by 0x4F38204: XrdCl::XRootDMsgHandler::Process(XrdCl::Message*)
>> (XrdClXRootDMsgHandler.cc:300)
>> ==13424== by 0x4F198D1: XrdCl::Stream::HandleIncMsgJob::Run(void*)
>> (XrdClStream.hh:279)
>> ==13424== by 0x4F6FFED: XrdCl::JobManager::RunJobs()
>> (XrdClJobManager.cc:148)
>> ==13424== by 0x4F6FB37: RunRunnerThread (XrdClJobManager.cc:33)
>>
>> Is there something that sticks out at you? Code attached.
>>
>> Thanks,
>> -Daniel
>>
>>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
|