[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