Strange crash of Qt 4.8.4 QList under Apple LLVM

Question

Does anybody know why this code crashes?

Code that crashes:

QList<int> lst;
const auto& tmp = QList<int>() << 1;
lst = tmp;

Code that works (tmp is not a reference):

QList<int> lst;
const auto tmp = QList<int>() << 1;
lst = tmp;

Compiler:

Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix 

Crash message:

qt_test(76726,0x7fff76257180) malloc: *** error for object 0x101208b60: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
qt_test: line 43: 76726 Abort trap: 6           $DBG_TEST "$@"

This message appears when 'lst' destructor called.

Under VisualStudio 2012 this code works well.

Answer 1

After thinking about this more, I finally noticed the glaring inconsistency.

QList<int> lst;
const auto& tmp = QList<int>() << 1;
lst = tmp;

Specifically, looking at this line:

const auto& tmp = QList<int>() << 1;

QList<int>() is a temporary. This temporary is being passed into QList<int>::operator<<(...) , which is then returning it back as a reference. The problem here is the level of indirection; if you tried to store QList<int>() into a const-reference, it should live until the const-reference fell out of scope. But that reference was instead passed to an operator as this , and is lost by the end of the statement.

Why this works in Visual Studio and not GCC is questionable. A quick Google for answers turns up at least one interesting result where it points to the following clauses in the standard:

If the initializer expression is an rvalue, with T2 a class type, and “cv1 T1″ is reference-compatible with “cv2 T2,” the reference is bound in one of the following ways (the choice is implementation defined):

The reference is bound to the object represented by the rvalue or to a subobject with that object

A temporary of type “cv1 T2″ is created, and a constructor is called to copy the entire rvalue object into the temporary. This reference is bound to the temporary or to a subobject with the temporary.

So, it looks like Visual Studio is taking the second approach, which happens to make a difference in this edge case, since the value will be copied in the statement anyways. It really does put into question the usefulness of a const-reference, though.