[LLVMbugs] [Bug 9615] New: Missing destructor call on objects returned from operator->

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Apr 2 19:39:44 PDT 2011


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: unassignedclangbugs at nondot.org
        ReportedBy: ejtttje at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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.



More information about the llvm-bugs mailing list