Bug 59713 - unordered_map constructor / destructor / move
Summary: unordered_map constructor / destructor / move
Status: RESOLVED DUPLICATE of bug 60367
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-07 23:21 UTC by Victor Robertson
Modified: 2014-03-04 11:20 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-01-09 00:00:00


Attachments
intermediate files (72.64 KB, text/plain)
2014-01-07 23:21 UTC, Victor Robertson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Robertson 2014-01-07 23:21:19 UTC
Created attachment 31769 [details]
intermediate files

Running the sample program produces the following:

a.out(49621,0x7fff7df24310) malloc: *** error for object 0x7fa472c03880: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

Sample program:

#include <unordered_map>

struct Foo : std::unordered_map<int,int> {
    using std::unordered_map<int, int>::unordered_map;
    // ~Foo() = default; // explicitly adding default destructor fixes the problem
};

struct Bar {
    Bar(Foo f = {}) : _f(std::move(f)) {}
    // any of these constructors also work:
    // Bar(Foo f = Foo()) : _f(std::move(f)) {}
    // Bar(Foo f = {}) : _f(f) {}
    
    Foo _f;
};

int main() {
    Bar b;
    
    // The following code also works as expected
    // Foo f1 = {};
    // Foo f2 = std::move(f1);
}

Output from g++-4.9 -v:

Using built-in specs.
COLLECT_GCC=gcc-4.9
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc49/4.9-20131229/libexec/gcc/x86_64-apple-darwin13.0.0/4.9.0/lto-wrapper
Target: x86_64-apple-darwin13.0.0
Configured with: ../configure --build=x86_64-apple-darwin13.0.0 --prefix=/usr/local/Cellar/gcc49/4.9-20131229 --enable-languages=c,c++,objc,obj-c++ --program-suffix=-4.9 --with-gmp=/usr/local/opt/gmp4 --with-mpfr=/usr/local/opt/mpfr2 --with-mpc=/usr/local/opt/libmpc08 --with-cloog=/usr/local/opt/cloog018 --with-isl=/usr/local/opt/isl011 --with-system-zlib --enable-version-specific-runtime-libs --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --enable-plugin --disable-nls --disable-multilib
Thread model: posix
gcc version 4.9.0 20131229 (experimental) (GCC) 

Compiler command: g++-4.9 -Wall -Wextra --std=c++11 gcctest.cpp
No compiler output during compilation.

I've attached the intermediate files as requested.
Comment 1 Jonathan Wakely 2014-01-09 17:35:56 UTC
I think this is a front-end issue, the temporary gets destroyed twice
Comment 2 Jonathan Wakely 2014-01-09 17:53:44 UTC
bah, no it doesn't, my test was faulty. The same libstdc++ code compiled with clang doesn't have any memory errors though.
Comment 3 Victor Robertson 2014-01-09 17:57:53 UTC
I was thinking that might be the case, I'll see if I can move the report to the appropriate section.
Comment 4 Jonathan Wakely 2014-01-09 18:05:37 UTC
I wasn't going to change the component until we've definitely ruled out libstdc++ ... I'll keep looking into it
Comment 5 Victor Robertson 2014-01-10 23:37:11 UTC
My apologies!

I'm not sure why I first thought it was with libstdc++, but after realizing that just adding that explicitly defined default destructor fixed it, I couldn't imagine it being the library.
Comment 6 Jonathan Wakely 2014-03-04 11:20:01 UTC
Bug 60367 has a better testcase and analysis

*** This bug has been marked as a duplicate of bug 60367 ***