[Issue 14639] New: Assigning init value to struct uses stack, causing segfault

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14639

          Issue ID: 14639
           Summary: Assigning init value to struct uses stack, causing
                    segfault
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: DMD
          Assignee: nobody at puremagic.com
          Reporter: tomerfiliba at gmail.com

Consider the following snippet:

    struct Biggy {
        ulong[50000] a;
    }
    __gshared Biggy biggy;

    void main() {
        biggy = Biggy.init;
    }

produces the following code

    Dump of assembler code for function _Dmain:
    ...
    => 0x000000000047fa04 <+4>:    movabs $0x6faef0,%rsi
       0x000000000047fa0e <+14>:    movabs $0x7d6a90,%rdi
       0x000000000047fa18 <+24>:    mov    $0x1b774,%ecx
       0x000000000047fa1d <+29>:    rep movsq %ds:(%rsi),%es:(%rdi)

which is fine. However, adding a @disable this(this) to Biggy, i.e.,

    struct Biggy {
        ulong[50000] a;
        @disable this(this);
    }

produces

    Dump of assembler code for function _Dmain:
    ...
    => 0x000000000047fba4 <+4>:    movabs $0x7d6a88,%rsi
       0x000000000047fbae <+14>:    mov    $0x1b774,%ecx
       0x000000000047fbb3 <+19>:    pushq  (%rsi)
       0x000000000047fbb5 <+21>:    sub    $0x8,%rsi
       0x000000000047fbb9 <+25>:    loop   0x47fbb3 <_Dmain+19>
       0x000000000047fbbb <+27>:    movabs $0x7d6a90,%rdi
       0x000000000047fbc5 <+37>:    callq  0x47fb70
<_D7themain5Biggy8opAssignMFNaNbNcNiNjNfS7themain5BiggyZS7themain5Biggy>
       0x000000000047fbca <+42>:    add    $0xdbba0,%rsp

which, as you can see, copies Biggy.init onto the *stack* and then calls
opAssign on it. Notice that Biggy does not define opAssign, and even if it did,
 it doesn't make sense to *copy* the type's init to a temp location. 

Now since Biggy is big (~400KB), and the function is run on a stack-constrained
fiber, we got a very peculiar segfault. 

Is there any reason for this odd behavior? I would have used memcpy, but
&Biggy.init won't compile. 


-tomer (weka.io)

--