Segfault with std.container.Array but not regular dynamic array

Dan dbdavidson at yahoo.com
Wed Nov 28 14:13:03 PST 2012


On Wednesday, 28 November 2012 at 20:30:41 UTC, Maxim Fomin wrote:
> On Wednesday, 28 November 2012 at 18:08:59 UTC, Dan wrote:
>
> This code with version=bug produces garbage because of 
> opAssign. It seems that opAssign is actually called before 
> accessing map:
>

Maxim, thanks for looking more at this. This bug is not affecting 
my work in any way - I'm just trying to learn more about D and 
how to debug, and your responses are helpful.

I've now built druntime and phobos with debug to see if I can see 
what is going on more.

For me the relevant assembly of your code looks like below. I see 
the value in the assoc array get created and memset initialized 
to 0 inside aaA.d function _aaGetX with this line:

     memset(ptail + aligntsize(keytitsize), 0, valuesize); // zero 
value

Then between +62 and +102 it goes off the rails and upon entry to 
opAssign *this* is likely garbage. I can't be certain because the 
values I see are 0, which would be consistent with 0 
initialization - but could also just be luck. At this point I 
wish I knew some assembly. Anyway, I don't know if it is a 
problem with associative array code, per se, or the code 
generated by the compiler when opAssign and/or postblit are 
defined for the value type. I do know that if you have no 
postblit and no opAssign there are no issues - even with a 
destructor. This is consistent with the examples you have shown, 
they have postblit and/or opAssign as well as the RefCount code 
which has postblit and dtor. In both your example crash and the 
RefCount crash the actual seg fault is in the dtor accessing 
bogus data because as you pointed out it was not correctly 
initialized.

Thanks
Dan

    0x000000000041a630 <+0>:	push   %rbp
    0x000000000041a631 <+1>:	mov    %rsp,%rbp
    0x000000000041a634 <+4>:	sub    $0x38,%rsp
    0x000000000041a638 <+8>:	push   %rbx
    0x000000000041a639 <+9>:	mov    $0x3,%eax
    0x000000000041a63e <+14>:	mov    %eax,-0x30(%rbp)
    0x000000000041a641 <+17>:	lea    -0x30(%rbp),%rcx
    0x000000000041a645 <+21>:	movabs $0x8,%rdx
    0x000000000041a64f <+31>:	movabs $0x43cc10,%rsi
    0x000000000041a659 <+41>:	mov    %fs:0x0,%rdi
    0x000000000041a662 <+50>:	add    0x229957(%rip),%rdi        # 
0x643fc0
    0x000000000041a669 <+57>:	callq  0x41ae84 <_aaGetX>
    0x000000000041a66e <+62>:	mov    %rax,-0x28(%rbp)
    0x000000000041a672 <+66>:	test   %rax,%rax
    0x000000000041a675 <+69>:	jne    0x41a681 <_Dmain+81>
    0x000000000041a677 <+71>:	mov    $0x12,%edi
    0x000000000041a67c <+76>:	callq  0x41a710 <_D5again7__arrayZ>
=> 0x000000000041a681 <+81>:	movabs $0x2a,%rax
    0x000000000041a68b <+91>:	mov    %rax,-0x18(%rbp)
    0x000000000041a68f <+95>:	mov    %rax,%rsi
    0x000000000041a692 <+98>:	lea    -0x20(%rbp),%rdi
    0x000000000041a696 <+102>:	callq  0x41a5c8 
<_D5again1S8opAssignMFS5again1SZv>



More information about the Digitalmars-d-learn mailing list