Issue 15044 - [REG2.068.0] destroy might leak memory
Summary: [REG2.068.0] destroy might leak memory
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P1 regression
Assignee: No Owner
URL:
Keywords: pull, rejects-valid
Depends on:
Blocks:
 
Reported: 2015-09-11 21:53 UTC by Martin Nowak
Modified: 2015-09-24 08:15 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Martin Nowak 2015-09-11 21:53:18 UTC 
cat > bug.d << CODE
struct Vector
{
    ~this()
    {
    }

    RefCounted!Vector dup()
    {
        return RefCounted!Vector(&this);
    }
}

struct RefCounted(T)
{
    ~this()
    {
        .destroy(*t); // __xdtor of Vector not yet available
        static assert(__traits(hasMember, T, "__xdtor"));
    }
    T* t;
}
CODE

dmd -c bug
----
bug.d(18): Error: static assert  (__traits(hasMember, Vector, "__xdtor")) is false
bug.d(7):        instantiated from here: RefCounted!(Vector)
----

The problem is that __xdtor is not yet available when the destructor of RefCounted is analyzed, hence .destroy won't call the destructor of Vector.
It seems that the creation of __xdtor should happen earlier.
Comment 1 Martin Nowak 2015-09-12 00:07:01 UTC 
This breaks b/c of the following semantic analysis issue.

Vector.semantic
dup.semantic
RefCounted!Vector.semantic (return type)
RefCounted!Vector buildOpAssign
RefCounted!Vector.dtor.semantic3 (buildOpAssign)

It seems that buildOpAssign is too greedy running semantic3 during a semantic1 pass of a struct.
Comment 2 Martin Nowak 2015-09-12 01:26:52 UTC 
Any idea how to solve this @Kenji?
We could try to do semantic3 for buildOpAssign later, but then we'd have to add a special case to op_overload and gag assign usage or so.
Comment 3 Kenji Hara 2015-09-14 10:44:06 UTC 
(In reply to Martin Nowak from comment #2)
> Any idea how to solve this @Kenji?
> We could try to do semantic3 for buildOpAssign later, but then we'd have to
> add a special case to op_overload and gag assign usage or so.

I think currently there's no way than treat the generated opAssign function specially.

I'll post a PR soon.
Comment 5 github-bugzilla 2015-09-14 17:44:00 UTC 
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/8e4676303a688ce3a034b38508b5e5b8c7bfa7e0
fix Issue 15044 - destroy might leak memory

Defer semantic3 running of generated `opAssign` function, and add special
error gagging mechanism in `FuncDeclaration.semantic3()` to hide errors
from its body.

https://github.com/D-Programming-Language/dmd/commit/af4d3a4158f95d1720b42e8027ae2aead90c7a4f
Merge pull request #5075 from 9rnsr/fix15044

[REG2.068.0] Issue 15044 - destroy might leak memory