Hi Sandeep,

>> OS: RH EL (AS 3.0)
>> Hardware:
>> [root@CISCART27 sdi]# uname -a
>> Linux CISCART27 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17
>> 17:52:23 EDT 2005 i686 i686 i386 GNU/Linux
>> ACE lib version: 5.3.5

Wow, you are using a VERY old version of ACE. I recommend that you
upgrade to ACE+TAO x.4.7, which you can download from

http://deuce.doc.wustl.edu/Download.html

under the heading "latest beta kit". Things have changed quite a bit
since then, so I suspect this memory leak has been fixed. Please see

http://www.cs.wustl.edu/~schmidt/ACE_wrapers/ace/OS_NS_stdio.inl

to see the latest code.

Thanks,

Doug

>> We are using ACE_File_Lock in our application as
>> below.
>> ACE_File_Lock checkLock(LockFile, RDONLY,0,0);
>>
>> if (checkLock.tryacquire() !=3D -1) {
>> Printf("tryacquir failed");
>> return false;
>> }
>>
>> Here appl1Lock is actually created by some other
>> application & we want to check if that file is present
>> (which means that app is running).
>>
>> The application is working fine. But in some cases the
>> LockFile may not be actaully be there & hence we see
>> error like "ACE_File_LOck::ACE_File_Lock <name of
>> LockFile> no such file or directory", which is also
>> ok.
>>
>> But, when the application is run with valgrind(memory
>> leak checking tool), it reports that memory allocated
>> with strdup() in the constructor ACE_File_Lock is not
>> being freed for some cases.
>>
>> I looked at the ACE code. Though I did not look at it
>> thoroughly, I felt in our case memory allocated using
>> strdup in ACE_OS::flock_init() in
>> ACE_File_Lock()::open() is not being freed in
>> ACE_OS::flock_destory().
>>
>> >From OS.i file
>> ----------------------------------------------
>> #if defined (CHORUS)
>> // Are we the owner?
>> if (lock->process_lock_ && lock->lockname_ !=3D 0)
>> {
>> // Only destroy the lock if we're the owner
>> ACE_OS::mutex_destroy (lock->process_lock_);
>> ACE_OS::munmap (lock->process_lock_,
>> sizeof (ACE_mutex_t));
>> if (unlink_file)
>> ACE_OS::shm_unlink (lock->lockname_);
>> ACE_OS::free (ACE_static_cast (void *,
>>
>> ACE_const_cast (ACE_TCHAR *,
>>
>> lock->lockname_)));
>> }
>> else if (lock->process_lock_)
>> // Just unmap the memory.
>> ACE_OS::munmap (lock->process_lock_,
>> sizeof (ACE_mutex_t));
>> -----------------------------------------------
>>
>> I think in our case since we are not the owner of lock
>> file, lock->process_lock_ is not initialized and hence
>> memory allocated to lock->lockname is not freed.
>>
>> Please let me know if this is true.
>> Forgive me if I am wrong & explain how it works.

--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Institute for Software Integrated Systems WEB:
www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203 NET: d.schmidt@...