On Tuesday, 11 June 2013 at 06:00:01 UTC, Andrei Alexandrescu wrote:
> On 6/11/13 12:22 AM, Andrei Alexandrescu wrote:
>> On 6/10/13 6:10 PM, Jerry wrote:
>>> [pid 23169]
>>> open("/home/jlquinn/dmd2/linux/bin64/../lib64/libphobos2.a",
>>> O_RDONLY|O_CLOEXEC) = 11
>>
>> OK, so it seems this is the cause. I'm trying to repro it on a fresh
>> Ubuntu 12.10 VM. So at least two bugs:
>>
>> 1. We link dynamically by default at least on some systems.
>>
>> 2. The dynamically linked programs crash again at least on some systems.
>
> Was unable to repro on a fresh installation of ubu 12.10/64 in a VirtualBox on OSX. (It's clear there is a problem somewhere though.)
>
> Andrei

I asked twice for attaching binary produced by compiler.
It would allow to see if the problem is with OP setup, hardware or system.
If their binary will crash on our system, then something with D(md) itself is borken.

It would also allow for disassembling and better debugging by interested in solving problem people.

But I am totally ignored here.
Andrei, can you help? ;)

On 6/11/13 5:17 AM, nazriel wrote:
> On Tuesday, 11 June 2013 at 06:00:01 UTC, Andrei Alexandrescu wrote:
>> On 6/11/13 12:22 AM, Andrei Alexandrescu wrote:
>>> On 6/10/13 6:10 PM, Jerry wrote:
>>>> [pid 23169]
>>>> open("/home/jlquinn/dmd2/linux/bin64/../lib64/libphobos2.a",
>>>> O_RDONLY|O_CLOEXEC) = 11
>>>
>>> OK, so it seems this is the cause. I'm trying to repro it on a fresh
>>> Ubuntu 12.10 VM. So at least two bugs:
>>>
>>> 1. We link dynamically by default at least on some systems.
>>>
>>> 2. The dynamically linked programs crash again at least on some systems.
>>
>> Was unable to repro on a fresh installation of ubu 12.10/64 in a
>> VirtualBox on OSX. (It's clear there is a problem somewhere though.)
>>
>> Andrei
>
> I asked twice for attaching binary produced by compiler.
> It would allow to see if the problem is with OP setup, hardware or system.
> If their binary will crash on our system, then something with D(md)
> itself is borken.
>
> It would also allow for disassembling and better debugging by interested
> in solving problem people.
>
> But I am totally ignored here.
> Andrei, can you help? ;)

Well Jerry can help. Jerry? Nazriel, if you want me to attach the binary I produced, sure, I can do that. But that works...

Andrei

"nazriel" <spam@dzfl.pl> writes:

> On Tuesday, 11 June 2013 at 06:00:01 UTC, Andrei Alexandrescu wrote:
>> On 6/11/13 12:22 AM, Andrei Alexandrescu wrote:
>>> On 6/10/13 6:10 PM, Jerry wrote:
>>>> [pid 23169]
>>>> open("/home/jlquinn/dmd2/linux/bin64/../lib64/libphobos2.a",
>>>> O_RDONLY|O_CLOEXEC) = 11
>>>
>>> OK, so it seems this is the cause. I'm trying to repro it on a fresh Ubuntu 12.10 VM. So at least two bugs:
>>>
>>> 1. We link dynamically by default at least on some systems.
>>>
>>> 2. The dynamically linked programs crash again at least on some systems.
>>
>> Was unable to repro on a fresh installation of ubu 12.10/64 in a VirtualBox on OSX. (It's clear there is a problem somewhere though.)
>>
>> Andrei
>
> I asked twice for attaching binary produced by compiler.
> It would allow to see if the problem is with OP setup, hardware or system.
> If their binary will crash on our system, then something with D(md) itself is
> borken.
>
> It would also allow for disassembling and better debugging by interested in solving problem people.
>
> But I am totally ignored here.
> Andrei, can you help? ;)

Sorry about that.  I was hesitant to post a binary to a newsgroup.

http://d.puremagic.com/issues/attachment.cgi?id=1224

Thanks for looking,
Jerry

On Tuesday, 11 June 2013 at 12:40:23 UTC, Andrei Alexandrescu wrote:
>
> Well Jerry can help. Jerry? Nazriel, if you want me to attach the binary I produced, sure, I can do that. But that works...
>
> Andrei

Thanks to your authority, your posts are more visible than mine that's why I asked for help :PPP


On Tuesday, 11 June 2013 at 13:32:51 UTC, Jerry wrote:
> "nazriel" <spam@dzfl.pl> writes:
>
>
> Sorry about that.  I was hesitant to post a binary to a newsgroup.
>
> http://d.puremagic.com/issues/attachment.cgi?id=1224
>
> Thanks for looking,
> Jerry

Thanks a lot!

Few things I gathered so far:
It isn't your setup/system/hardware problem when launching application. It does also segfault on my system. So for some reason DMD or/and linker produce broken executable on your system.

I created same hello world with same DMD revision and segfault doesn't occur when I launch created binary on my machine.

From fast debugging and reversing looks like segfault occurs in
_d_dso_registry. We may want to ping Martin Nowak with that because it seems to be related to shared libraries which is his baby.

Segfault occurs exactly at this instruction:
=> 0x00000000004187b0 <+512>:	mov    QWORD PTR [rax-0x8],r14

I created an breakpoint at 1 instruction before the one mentioned above.
Reg info:

Breakpoint 1, 0x00000000004187ac in _d_dso_registry ()
(gdb) info reg
rax            0x43d0a0	4444320
rbx            0x1	1
rcx            0x10043d0a0	4299411616
rdx            0x43d0a0	4444320
rsi            0x0	0
rdi            0x4	4
rbp            0x7fffffffe8d0	0x7fffffffe8d0
rsp            0x7fffffffe810	0x7fffffffe810
r8             0x3	3
r9             0x7fffffffe760	140737488349024
r10            0x7fffffffe5a0	140737488348576
r11            0x7ffff7686320	140737344201504
r12            0x400270	4194928
r13            0x43d050	4444240
r14            0x43d010	4444176
r15            0x1	1
rip            0x4187ac	0x4187ac <_d_dso_registry+508>
eflags         0x206	[ PF IF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0

I can't find address pointed by RAX+SIB in IDA listing unless I am missing something.

I compared assembly created by my working binary and your's and there few interesting things:

Working binary:
mov    rbx,QWORD PTR [rip+0x247b30]        # 0x680808 <_D2rt14sections_linux12_static_dsosS2rt4util9container36__T5ArrayTPS2rt14sections_linux3DSOZ5Array+8>

Borked one:
mov    rbx,QWORD PTR [rip+0x2359c]        # 0x43bd24 <_D2rt14sections_linux12_static_dsosS2rt4util9container36__T5ArrayTPS2rt14sections_linux3DSOZ5Array+4>

See the 4 vs 8 offset