Bug 8923 – Nested structs have null context pointers in static array variables and struct fields

The destructor of the member of a struct doesn't get called when I expect it to be called. I'd expect it to be called at the end of the destructor of the containing struct. I'm not sure when it gets called instead, but it is too late. Here is a case that segfaults in DMD 2.060: void main() { bool destructorCalled = false; struct DestructorCounter { ~this() { destructorCalled = true; // segmentation fault } } struct S { DestructorCounter a; } S s; } If this is supposed to be invalid I can provide examples that are most definitely not supposed to be invalid, but are a bit more lengthy.

It seems that dmd doesn't pass allocated value correctly. In this case it emits in main function code: callq <_d_allocmemory> movq $0x0,(%rax) movb $0x0,0x8(%rax) lea -0x8(%rbp),%rax xor %rcx,%rcx mov %rcx,(%rax) mov %rax,%rdi So, allocated value is overwritten and destructor gets incorrect pointer in %rdi. However, if the case is simplified to one level (replace S s; with DestructorCounter s;) dmd emits correct code: callq <_d_allocmemory> movq $0x0,(%rax) movb $0x0,0x8(%rax) mov %rax,-0x8(%rbp) lea -0x8(%rbp),%rax xor %rcx,%rcx mov %rax,%rdi Now %rdi points to allocated memory. Probably, because S field destructor doesn't access destructorCalled object forces dmd to pass invalid value.

In Windows, s1's dtor causes Access Violation, but s2's dtor runs successfully. import core.stdc.stdio : printf; void main() { bool destructorCalled = false; struct DestructorCounter { ~this() { printf("-dtor\n"); destructorCalled = true; // segmentation fault } } struct S { DestructorCounter a; } S s1; // Access Violation S s2 = S(); // OK } Output: --- -dtor (s2's dtor call) -dtor (s1's dtor call) object.Error: Access Violation --- I think this is definitely a wrong-code bug.

I debugged the issue I was having further, and it is definitely a different problem than I thought it was. It does not have to do with destructors being called in the wrong order, and actually the test case from the first post isn't showing the problem that I encountered. It was just that once I had that test case I felt like I should submit it. I'll try to figure out a test case for my real problem, but I'll do that in a different bug report.

Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/585f5a3a3db9f856dc4904910b8a705969b89d33 fix Issue 8923 - Destructors of struct members get called at the wrong point https://github.com/D-Programming-Language/phobos/commit/f76ea73eff85d260f6b1642dbada9701dc3a7fa6 Merge pull request #926 from 9rnsr/fix8923 Supplemental fix for Issue 8923

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/704230b135f3e4b25470b4522927fe97a43604c1 fix Issue 8923 - Destructors of struct members get called at the wrong point If a default-initialized variable declaration requies some frame pointers for it's field, they should be initialized by the StructLiteralExp to fill the hidden field. https://github.com/D-Programming-Language/dmd/commit/e1c9119d2a622ecf4bfc3b5c34f20a33f7f4a2c1 Merge pull request #1259 from 9rnsr/fix8923 Issue 8923 - Destructors of struct members get called at the wrong point

As commits are already pushed referencing this one, renaming the issue and providing a comprehensive example (instead of creating a new one one marking this as a duplicate): --- void main() { int i; struct CS { void f() { ++i; } } struct S { CS cs; } CS cs; assert(cs.tupleof[$-1] != null); // ok CS[1] csArr; assert(csArr[0].tupleof[$-1] != null); // fails S s1 = S(); assert(s1.cs.tupleof[$-1] != null); // ok S s2; assert(s2.cs.tupleof[$-1] != null); // fails } ---

*** Issue 8951 has been marked as a duplicate of this issue. ***

*** Issue 8952 has been marked as a duplicate of this issue. ***

Please, when you are fixing issues with such incorrect descriptions, create a new one and mark this as a duplicate or rename this one to have a correct title in commit message. Thanks.