Bug 1079788
| Summary: | c++11: Passing a std::unique_ptr to a function called through a pointer based on a lambda triggers dtor | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Machata <pmachata> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 23 | CC: | jakub, jason, jwakely, law, mnewsome |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-24 11:50:58 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This seems to be a G++ bug, in the code generated for the lambda. The same problem happens if you remove all library dependencies:
struct valfile
{
int i = 0;
};
struct valfile_ptr
{
valfile_ptr(valfile* p) : ptr(p) { }
valfile_ptr(valfile_ptr&& u) : ptr(u.ptr) { u.ptr = nullptr; }
~valfile_ptr() { delete ptr; }
valfile* ptr;
};
void
pop_each (valfile_ptr p,
valfile_ptr (*f) (valfile_ptr)
)
{
f (static_cast<valfile_ptr&&> (p));
}
void
operate (valfile_ptr p)
{
auto f = [] (valfile_ptr vf) -> valfile_ptr
{
vf.ptr->i = 1;
return vf;
};
return pop_each (static_cast<valfile_ptr&&> (p), f);
}
int
main()
{
operate (valfile_ptr { new valfile {} });
}
Printing the values of the "this" pointers shows we move-construct the return value in the lambda from an invalid address:
extern "C" int printf(const char*, ...);
struct valfile
{
int i = 0;
};
struct valfile_ptr
{
valfile_ptr(valfile* p) : ptr(p) {
printf("Construct %p (%p)\n", this, p);
}
valfile_ptr(valfile_ptr&& u) : ptr(u.ptr) {
u.ptr = nullptr;
printf("Move %p from %p (%p)\n", this, &u, ptr);
}
~valfile_ptr() {
printf("Destroy %p (%p)\n", this, ptr);
// delete ptr;
}
valfile* ptr;
};
void
pop_each (valfile_ptr p,
valfile_ptr (*f) (valfile_ptr)
)
{
printf("In pop_each\n");
f (static_cast<valfile_ptr&&> (p));
}
void
operate (valfile_ptr p)
{
printf("In operate\n");
auto f = [] (valfile_ptr vf) -> valfile_ptr
{
printf("In lambda\n");
vf.ptr->i = 1;
return vf;
};
return pop_each (static_cast<valfile_ptr&&> (p), f);
}
int
main()
{
operate (valfile_ptr { new valfile {} });
}
Construct 0x7fff03584d00 (0x1ca2010)
In operate
Move 0x7fff03584cd0 from 0x7fff03584d00 (0x1ca2010)
In pop_each
Move 0x7fff03584c80 from 0x7fff03584cd0 (0x1ca2010)
In lambda
Move 0x7fff03584c70 from 0x7fff03584c30 (0x1ca2010)
Destroy 0x7fff03584c70 (0x1ca2010)
Destroy 0x7fff03584c80 (0x1ca2010)
Destroy 0x7fff03584cd0 ((nil))
Destroy 0x7fff03584d00 ((nil))
The last "Move" line shows we call the move constructor with an argument with address 0x7fff03584c30 but no object was ever constructed at that address. Somehow it gets the correct ptr value anyway, 0x1ca2010, but another valfile_ptr still owns it, so they both try to delete it.
should this go to the upstream bugzilla? reported upstream as https://gcc.gnu.org/PR62052 This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Still present in F23, but not in GCC 6.1 or trunk. I'll track down when it got fixed. Fixed upstream by https://gcc.gnu.org/r233733 This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This is fixed in F24 and a backport to F23 seems unlikely at this time. |
The following code is causing the problem: --- #include <vector> #include <memory> typedef std::vector <int> valfile; typedef std::unique_ptr <valfile> valfile_ptr; void pop_each (valfile_ptr p, //std::function <valfile_ptr (valfile_ptr)> f valfile_ptr (*f) (valfile_ptr) ) { f (std::move (p)); } void operate (valfile_ptr p) { auto f = [] (valfile_ptr vf) -> valfile_ptr { vf->push_back (1); return vf; }; return pop_each (std::move (p), f); } int main(int argc, char *argv[]) { operate (valfile_ptr { new valfile {} }); return 0; } --- It seems one more ~unique_ptr is triggered at the point of std::move, and the references to the underlying vector end up invalid and are reported by valgrind (edited to remove visual clutter): ==11627== Invalid read of size 8 ==11627== at 0x4011CF: std::vector::~vector (stl_vector.h:416) ==11627== by 0x401011: std::default_delete::operator() (unique_ptr.h:67) ==11627== by 0x400DC0: std::unique_ptr::~unique_ptr (unique_ptr.h:184) ==11627== by 0x400998: pop_each (p2.cc:13) ==11627== by 0x400AA3: operate (p2.cc:24) ==11627== by 0x400B14: main (p2.cc:29) ==11627== Address 0x596a048 is 8 bytes inside a block of size 24 free'd ==11627== at 0x4C272DF: operator delete(void*) (in valgrind) ==11627== by 0x401019: std::default_delete::operator() (unique_ptr.h:67) ==11627== by 0x400DC0: std::unique_ptr::~unique_ptr() (unique_ptr.h:184) ==11627== by 0x40098C: pop_each (p2.cc:13) ==11627== by 0x400AA3: operate (p2.cc:24) ==11627== by 0x400B14: main (p2.cc:29) (And a bunch more, including a complaint about duplicate delete.) Converting the function pointer to std::function (as indicated by the commented-out line) fixes the problem, as does changing the lambda into simple global function. That makes me think that it's GCC's fault rather than my own, but really I'm not entirely sure. # LANG=C gcc --version gcc (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1) On a locally-built package based on Red Hat SPRM, I can reproduce the problem (and make it go away as described above) with the following GCC as well: $ LANG=C ~/opt/gcc482/usr/bin/gcc --version gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)