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