[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] c++ client handle leak ?
Quartier, Nicolas wrote:
I tried everyhting you suggested, but with no success.
Boundschecker reports the same problems.
Even when running the SubscribeDemo.exe (c++ demo),
I see the number of handles increasing (in windows task manager).
Since I'm on win2000, I tried also on a winXP machine, but also
with no success.
I tried glowcode, but it also did not show a problem.
I'll continue to look for a solution ...
i have tested now many variations on Linux with valgrind
and found with one situation a memory leak (during reconnect polling).
The fix is available with subversion.
On Linux everything looks stable and solid now.
I'm not sure if this helps to solve your problem on Windows,
please keep me informed,
From: owner-xmlblaster at server.xmlBlaster.org
[mailto:owner-xmlblaster at server.xmlBlaster.org]On Behalf Of Marcel Ruff
Sent: donderdag 28 oktober 2004 21:31
To: xmlblaster at server.xmlBlaster.org
Subject: Re: [xmlblaster] c++ client handle leak ?
my pthread_detach() was a flop as the thread
was set to detached already, so i went back to the original
But the pthread.dll could be the problem as they state
a memory leak for destroyed threads, see
I have no updated pthreads.dll from
and added it to our subversion.
Could you please get the code from subversion and verify
with your BoundChecker that it is fixed?
My tests with http://www.glowcode.com/ on Windows XP
did not show any problem.
> Hi Nicolas,
> i think i have found the bug.
> A call to pthread_detach() was missing to reclaim the resources
> of the callback thread.
> Could you please get the code from subversion and verify
> with your BoundChecker that it is fixed?
> Quartier, Nicolas wrote:
>> Hi Marcel,
>> I think it are thread handles, but I'm not sure.
>> I saw the number of handles increasing initialy with the task manager.
>> Now I'm using boundschecker. At program termination a lot of resource
>> are reported in pthreadVC.dll. But for the rest I'm not getting much
>> information about it.
>> Next to this boundschecker also reports a memory leak of 32 bytes for
>> every call:
>> "requestInfoP = xb->postSendEvent(&requestInfo, exception);"
>> on line 566 in xmlblasterconnectionunparsed.c
>> According to boundschecker the memory is allocated in pthreadVC.dll
>> I also used process explorer.
>> In process explorer I see the handle count increasing, but the handle
>> itself is not added
>> to the list of handles.
>> Kind regards,
>> -----Original Message-----
>> From: owner-xmlblaster at server.xmlBlaster.org
>> [mailto:owner-xmlblaster at server.xmlBlaster.org]On Behalf Of Marcel Ruff
>> Sent: donderdag 28 oktober 2004 16:01
>> To: xmlblaster at server.xmlBlaster.org
>> Subject: Re: [xmlblaster] c++ client handle leak ?
>> Quartier, Nicolas wrote:
>> > Hi,
>> > I'm writing a c++ client using XB library 0.91 on win 2000.
>> > The client connects to the server using sockets.
>> > Does anyone know of a handle leak in the client?
>> > Because everytime the client pings the server,
>> > the number of handles of my client program is increased with 4.
>> > The memory usage and the number of threads are stable though.
>> > Maybe I'm something wrong ?
>> File descriptor handles or socket specific handles?
>> How do you measure the consumed handles?
>> > Thanks and kind regards,
>> > Nicolas.
>> > - - - - - - - DISCLAIMER - - - - - - - -
>> > Unless indicated otherwise, the information contained in this
>> message is
>> > privileged and confidential, and is intended only for the use of the
>> > addressee(s) named above and others who have been specifically
>> > authorized to receive it. If you are not the intended recipient,
>> you are
>> > hereby notified that any dissemination, distribution or copying of
>> > message and/or attachments is strictly prohibited. The company
>> > no liability for any damage caused by any virus transmitted by this
>> > email. Furthermore, the company does not warrant a proper and
>> > transmission of this information, nor does it accept liability
>> > delays. If you have received this message in error, please
>> > sender and delete the message. Thank you.