http://llvm.org/bugs/show_bug.cgi?id=9615

           Summary: Missing destructor call on objects returned from
                    operator->
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: [email protected]
        ReportedBy: [email protected]
                CC: [email protected], [email protected]


Created an attachment (id=6392)
 --> (http://llvm.org/bugs/attachment.cgi?id=6392)
Demonstrates the bug.

I am using Xcode 4 with Mac OS X 10.6.7.

I have a piece of code which attempts to use RAII for wrapping a mutex around
calls to a resource class.

There is an Accessor class which overloads operator->().  This returns an
instance of the Lock class, which handles mutex operations in its constructor
and destructor.  The Lock also overrides operator->() to return a pointer to
the resource in question.  (Sample code attached)

This works with g++ across a variety of versions (e.g. 4.2.1 on OS X or 4.4.3
on Ubuntu), as well as llvm-g++ on OS X.  The expected output is:

TEST 1
Lock Acquired 0x7fff5fbff738
Hello World!
Lock Released 0x7fff5fbff738

TEST 2
Lock Acquired 0x7fff5fbff740
Hello World!
Lock Released 0x7fff5fbff740

However, when compiled by clang (Apple clang version 2.0
(tags/Apple/clang-137))

TEST 1
Lock Acquired 0x7fff5fbff760
Hello World!

TEST 2
Lock Acquired 0x7fff5fbff758
Hello World!
Lock Released 0x7fff5fbff758

Notice the Lock in the first test is never destructed/released.

The difference with the second test is that a 'normal' function is called on
the Accessor, which returns the Lock, and then operator-> is called on that
directly.  In this case, destruction appears to work correctly.  It is the
'implicit' operator-> call in the first case which seems to screw up the
destruction call.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs

Reply via email to