DMD 2.063 produces broken binaries
Hi folks,
I've downloaded the current dmd 2.063 zip and tried it out. This is
Ubuntu 12.10 x86_64. Every program I compile segfaults when I try to
run it. As a simple example:
jlquinn@wyvern:~/re/test$ cat junk.d
import std.stdio;
void main() {
writeln("Hi");
}
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd junk.d
jlquinn@wyvern:~/re/test$ ./junk
Segmentation fault (core dumped)
The gdb backtrace is somewhere in __libc_start_main, before main() is
run.
I assume I'm not in the majority, but I literally can't compile and run
anything.
Any help would be appreciated
Thanks
Jerry
Re: DMD 2.063 produces broken binaries
On Tuesday, 4 June 2013 at 18:03:53 UTC, Jerry wrote:
Hi folks,
I've downloaded the current dmd 2.063 zip and tried it out.
This is
Ubuntu 12.10 x86_64. Every program I compile segfaults when I
try to
run it. As a simple example:
jlquinn@wyvern:~/re/test$ cat junk.d
import std.stdio;
void main() {
writeln("Hi");
}
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd
junk.d
jlquinn@wyvern:~/re/test$ ./junk
Segmentation fault (core dumped)
The gdb backtrace is somewhere in __libc_start_main, before
main() is
run.
I assume I'm not in the majority, but I literally can't compile
and run
anything.
Any help would be appreciated
Thanks
Jerry
Is this a clean install?
I'm using Debian, and had to fully remove the prev version before
installing the newer version otherwise I got linking issues. I
did however use the deb package, not the zip.
There's some discussion in another thread about doing proper deb
packaging, so I think the DMD devs know about these problems, at
least in the general sense.
--rt
Re: DMD 2.063 produces broken binaries
On Tuesday, 4 June 2013 at 18:03:53 UTC, Jerry wrote:
Hi folks,
I've downloaded the current dmd 2.063 zip and tried it out.
This is
Ubuntu 12.10 x86_64. Every program I compile segfaults when I
try to
run it. As a simple example:
jlquinn@wyvern:~/re/test$ cat junk.d
import std.stdio;
void main() {
writeln("Hi");
}
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd
junk.d
jlquinn@wyvern:~/re/test$ ./junk
Segmentation fault (core dumped)
The gdb backtrace is somewhere in __libc_start_main, before
main() is
run.
I assume I'm not in the majority, but I literally can't compile
and run
anything.
Any help would be appreciated
Thanks
Jerry
Try compiling with the -v -w flags for more verbose output. It
may be an installation problem.
Re: DMD 2.063 produces broken binaries
On Tuesday, 4 June 2013 at 18:03:53 UTC, Jerry wrote:
Hi folks,
I've downloaded the current dmd 2.063 zip and tried it out.
This is
Ubuntu 12.10 x86_64. Every program I compile segfaults when I
try to
run it. As a simple example:
jlquinn@wyvern:~/re/test$ cat junk.d
import std.stdio;
void main() {
writeln("Hi");
}
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd
junk.d
jlquinn@wyvern:~/re/test$ ./junk
Segmentation fault (core dumped)
The gdb backtrace is somewhere in __libc_start_main, before
main() is
run.
I assume I'm not in the majority, but I literally can't compile
and run
anything.
Any help would be appreciated
Thanks
Jerry
Similar problem, you aren't alone. Poster noticed the segfaults
after installing gdc.
http://forum.dlang.org/post/mailman.573.1370076049.13711.digitalmars-d-le...@puremagic.com
Re: DMD 2.063 produces broken binaries
"Rob T" writes: > On Tuesday, 4 June 2013 at 18:03:53 UTC, Jerry wrote: >> Hi folks, >> >> I've downloaded the current dmd 2.063 zip and tried it out. This is >> Ubuntu 12.10 x86_64. Every program I compile segfaults when I try to >> run it. As a simple example: > > Is this a clean install? > > I'm using Debian, and had to fully remove the prev version before installing > the newer version otherwise I got linking issues. I did however use the deb > package, not the zip. It was a clean install. I removed the prior dmd directory before unzipping. I also tried installing the deb package and still get a segfault.
Re: DMD 2.063 produces broken binaries
"Gary Willoughby" writes:
> On Tuesday, 4 June 2013 at 18:03:53 UTC, Jerry wrote:
>> Hi folks,
>>
>> I've downloaded the current dmd 2.063 zip and tried it out. This is
>> Ubuntu 12.10 x86_64. Every program I compile segfaults when I try to
>> run it. As a simple example:
>>
>> jlquinn@wyvern:~/re/test$ cat junk.d
>> import std.stdio;
>> void main() {
>> writeln("Hi");
>> }
>> jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd junk.d
>> jlquinn@wyvern:~/re/test$ ./junk
>> Segmentation fault (core dumped)
>>
>> The gdb backtrace is somewhere in __libc_start_main, before main() is
>> run.
>>
>> I assume I'm not in the majority, but I literally can't compile and run
>> anything.
>>
>> Any help would be appreciated
>> Thanks
>> Jerry
>
> Try compiling with the -v -w flags for more verbose output. It may be an
> installation problem.
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d
binary/home/jlquinn/dmd2/linux/bin64/dmd
version v2.063
config/home/jlquinn/dmd2/linux/bin64/dmd.conf
parse junk
importall junk
importobject
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/object.di)
importstd.stdio
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/stdio.d)
importcore.stdc.stdio
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stdio.d)
importcore.stdc.config
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/config.d)
importcore.stdc.stddef
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stddef.d)
importcore.stdc.stdarg
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stdarg.d)
importstd.string
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/string.d)
importcore.exception
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/exception.d)
importcore.vararg
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/vararg.d)
importcore.stdc.stdlib
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/stdlib.d)
importcore.stdc.string
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/string.d)
importstd.algorithm
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/algorithm.d)
importstd.c.string
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/c/string.d)
importcore.bitop
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/bitop.d)
importstd.array
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/array.d)
importcore.memory
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/memory.d)
importstd.ascii
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/ascii.d)
importstd.conv
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/conv.d)
importstd.math
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/math.d)
importcore.stdc.math
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/math.d)
importstd.range
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/range.d)
importstd.exception
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/exception.d)
importstd.traits
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/traits.d)
importstd.typetuple
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/typetuple.d)
importstd.typecons
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/typecons.d)
importstd.format
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/format.d)
importstd.bitmanip
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/bitmanip.d)
importstd.system
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/system.d)
importstd.functional
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/functional.d)
importstd.utf
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/utf.d)
importcore.stdc.errno
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/errno.d)
importstd.uni
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/uni.d)
importstd.container
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/container.d)
importstd.random
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/random.d)
importstd.c.time
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/c/time.d)
importcore.stdc.time
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/stdc/time.d)
importstd.numeric
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/numeric.d)
importstd.c.stdlib
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/c/stdlib.d)
importstd.complex
(/home/jlquinn/dmd2/linux/bin64/../../src/phobos/std/complex.d)
importcore.thread
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/thread.di)
importcore.time
(/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/core/time.d)
importcore.sys.p
Re: DMD 2.063 produces broken binaries
On 06/04/2013 08:03 PM, Jerry wrote:
Hi folks,
I've downloaded the current dmd 2.063 zip and tried it out. This is
Ubuntu 12.10 x86_64. Every program I compile segfaults when I try to
run it. As a simple example:
jlquinn@wyvern:~/re/test$ cat junk.d
import std.stdio;
void main() {
writeln("Hi");
}
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd junk.d
jlquinn@wyvern:~/re/test$ ./junk
Segmentation fault (core dumped)
I've opened a bug report
http://d.puremagic.com/issues/show_bug.cgi?id=10274. Please let's
continue the investigation there.
Re: DMD 2.063 produces broken binaries
On 6/4/13 10:30 PM, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 config/home/jlquinn/dmd2/linux/bin64/dmd.conf parse junk importall junk importobject (/home/jlquinn/dmd2/linux/bin64/../../src/druntime/import/object.di) [snip] Can anyone reproduce this problem? Thanks, Andrei
Re: DMD 2.063 produces broken binaries
On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 [snip] I've done a clean room attempt at reproducing the bug, was unable to. Jerry, anything you can think of that's unusual with your installation? Thanks, Andrei
Re: DMD 2.063 produces broken binaries
On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote: On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 [snip] I've done a clean room attempt at reproducing the bug, was unable to. Jerry, anything you can think of that's unusual with your installation? Forgot to mention - details at http://d.puremagic.com/issues/show_bug.cgi?id=10274 Andrei
Re: DMD 2.063 produces broken binaries
On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote: On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote: On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 [snip] I've done a clean room attempt at reproducing the bug, was unable to. Jerry, anything you can think of that's unusual with your installation? Forgot to mention - details at http://d.puremagic.com/issues/show_bug.cgi?id=10274 One thought that comes to mind - you may want to double-check LD_LIBRARY_PATH to make sure there's no stray reference to an old libphobos.a dir.
Re: DMD 2.063 produces broken binaries
"Andrei Alexandrescu" writes: > On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote: >> On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote: >>> On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 >>> [snip] >>> >>> I've done a clean room attempt at reproducing the bug, was unable >>> to. Jerry, anything you can think of that's unusual with your installation? >> >> Forgot to mention - details at >> http://d.puremagic.com/issues/show_bug.cgi?id=10274 > > One thought that comes to mind - you may want to double-check LD_LIBRARY_PATH > to make sure there's no stray reference to an old libphobos.a dir. LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian testing machine as well as my Ubuntu one. I'm pretty confused. Jerry
Re: DMD 2.063 produces broken binaries
On Monday, 10 June 2013 at 06:41:39 UTC, Jerry wrote: "Andrei Alexandrescu" writes: On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote: On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote: On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 [snip] I've done a clean room attempt at reproducing the bug, was unable to. Jerry, anything you can think of that's unusual with your installation? Forgot to mention - details at http://d.puremagic.com/issues/show_bug.cgi?id=10274 One thought that comes to mind - you may want to double-check LD_LIBRARY_PATH to make sure there's no stray reference to an old libphobos.a dir. LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian testing machine as well as my Ubuntu one. I'm pretty confused. Jerry I can't reproduce this anywhere. What's the output for these: gcc --version ldd --version Also, check for any stray installations or config files: find /usr /etc /opt /home/$(whoami) -name \*phobos\* -o -name \*druntime\* -o -name dmd\* 2>/dev/null Be warned that will take a while (a few minutes on my machine). Also, and I know this sounds stupidly simple, but have to tried re-downloading?
Re: DMD 2.063 produces broken binaries
On 6/10/13 2:41 AM, Jerry wrote: "Andrei Alexandrescu" writes: On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote: On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote: On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote: jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d binary/home/jlquinn/dmd2/linux/bin64/dmd version v2.063 [snip] I've done a clean room attempt at reproducing the bug, was unable to. Jerry, anything you can think of that's unusual with your installation? Forgot to mention - details at http://d.puremagic.com/issues/show_bug.cgi?id=10274 One thought that comes to mind - you may want to double-check LD_LIBRARY_PATH to make sure there's no stray reference to an old libphobos.a dir. LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian testing machine as well as my Ubuntu one. I'm pretty confused. Jerry Appreciate the work. (BTW nice to see you again, recall we talked at that NLP conference a while back.) Let's focus on Ubuntu/64 because that's what I have on my end too. 1. Which Ubuntu version are you using? 2. Can you compile and run "hello, world" in C? 3. If you replace the D call to writeln() with a call to printf(), does that work? 4. If you make any other calls into the stdlib aside from I/O, do they work? 5. Does gdb reveal anything interesting? Andrei
Re: DMD 2.063 produces broken binaries
On Tuesday, 4 June 2013 at 18:03:53 UTC, Jerry wrote:
Hi folks,
I've downloaded the current dmd 2.063 zip and tried it out.
This is
Ubuntu 12.10 x86_64. Every program I compile segfaults when I
try to
run it. As a simple example:
jlquinn@wyvern:~/re/test$ cat junk.d
import std.stdio;
void main() {
writeln("Hi");
}
jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd
junk.d
jlquinn@wyvern:~/re/test$ ./junk
Segmentation fault (core dumped)
The gdb backtrace is somewhere in __libc_start_main, before
main() is
run.
I assume I'm not in the majority, but I literally can't compile
and run
anything.
Any help would be appreciated
Thanks
Jerry
Can you upload somewhere your broken binary?
x86_64 EFL binary would be great!
Re: DMD 2.063 produces broken binaries
"John Colvin" writes: > On Monday, 10 June 2013 at 06:41:39 UTC, Jerry wrote: >> >> LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian >> testing machine as well as my Ubuntu one. I'm pretty confused. >> >> Jerry > > I can't reproduce this anywhere. What's the output for these: > > gcc --version > ldd --version jlquinn@wyvern:~/dmd2/src/dmd$ gcc --version gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jlquinn@wyvern:~/dmd2/src/dmd$ ldd --version ldd (Ubuntu EGLIBC 2.15-0ubuntu20.1) 2.15 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. > Also, check for any stray installations or config files: > find /usr /etc /opt /home/$(whoami) -name \*phobos\* -o -name \*druntime\* -o > -name dmd\* 2>/dev/null I ran and verified that there's no stray phobos or druntime libraries. > Be warned that will take a while (a few minutes on my machine). > Also, and I know this sounds stupidly simple, but have to tried > re-downloading? Already tried it. I also get a segfault on my Debian x86_64 machine. I've straced the dmd compile and it is using the correct libraries. Compressed, the binary is 175K. Is that OK to attach to the open bug? Jerry
Re: DMD 2.063 produces broken binaries
Andrei Alexandrescu writes:
> On 6/10/13 2:41 AM, Jerry wrote:
>> "Andrei Alexandrescu" writes:
>>
>>> On Sunday, 9 June 2013 at 17:23:16 UTC, Andrei Alexandrescu wrote:
On Sunday, 9 June 2013 at 17:22:36 UTC, Andrei Alexandrescu wrote:
> On Wednesday, 5 June 2013 at 02:30:37 UTC, Jerry wrote:
>> jlquinn@wyvern:~/re/test$ /home/jlquinn/dmd2/linux/bin64/dmd -v -w junk.d
>> binary/home/jlquinn/dmd2/linux/bin64/dmd
>> version v2.063
> [snip]
>
> I've done a clean room attempt at reproducing the bug, was unable
> to. Jerry, anything you can think of that's unusual with your
> installation?
Forgot to mention - details at
http://d.puremagic.com/issues/show_bug.cgi?id=10274
>>>
>>> One thought that comes to mind - you may want to double-check
>>> LD_LIBRARY_PATH
>>> to make sure there's no stray reference to an old libphobos.a dir.
>>
>> LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian
>> testing machine as well as my Ubuntu one. I'm pretty confused.
>>
>> Jerry
>
> Appreciate the work. (BTW nice to see you again, recall we talked at that NLP
> conference a while back.)
I do recall. I'm glad you ended up someplace you enjoy. That was a fun
conference.
> Let's focus on Ubuntu/64 because that's what I have on my end too.
>
> 1. Which Ubuntu version are you using?
I'm running 12.10 x86_64.
> 2. Can you compile and run "hello, world" in C?
That works fine.
> 3. If you replace the D call to writeln() with a call to printf(), does that
> work?
No, same problem. BTW, it's segfaulting in _d_dso_registry() before
main() gets run.
> 4. If you make any other calls into the stdlib aside from I/O, do they
> work?
It doesn't matter. The following program segfaults:
void main() {}
> 5. Does gdb reveal anything interesting?
Unfortunately there's no debugging symbols in _d_dso_registry(). I
assume the compiler is writing asm directly.
Jerry
Re: DMD 2.063 produces broken binaries
On Monday, 10 June 2013 at 16:52:51 UTC, Jerry wrote:
No, same problem. BTW, it's segfaulting in _d_dso_registry()
before
main() gets run.
4. If you make any other calls into the stdlib aside from I/O,
do they
work?
It doesn't matter. The following program segfaults:
void main() {}
5. Does gdb reveal anything interesting?
Unfortunately there's no debugging symbols in
_d_dso_registry(). I
assume the compiler is writing asm directly.
Jerry
I got a similar issue when upgrading to 2.063 on arch linux, so I
feel this may be relevant to the current problem. Heres the
backtrace for me.
#0 0x77286f54 in _d_arrayappendcd () from
/usr/lib/libphobos2.so.0.63
#1 0x7721f5c4 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#2 0x772781a2 in _aApplycd1 () from
/usr/lib/libphobos2.so.0.63
#3 0x7721f566 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#4 0x77278626 in _aApplycd2 () from
/usr/lib/libphobos2.so.0.63
#5 0x7721f4b5 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#6 0x771b4f15 in std.encoding.EncodingScheme.register()
() from /usr/lib/libphobos2.so.0.63
#7 0x771b543a in
std.encoding.EncodingSchemeASCII._sharedStaticCtor9() ()
from /usr/lib/libphobos2.so.0.63
#8 0x771bb351 in std.encoding.__modsharedctor() () from
/usr/lib/libphobos2.so.0.63
#9 0x77288c54 in rt.minfo.ModuleGroup.runCtors() () from
/usr/lib/libphobos2.so.0.63
#10 0x77288196 in rt.minfo.ModuleGroup.runCtors() () from
/usr/lib/libphobos2.so.0.63
#11 0x772884dd in rt.minfo.rt_moduleCtor() () from
/usr/lib/libphobos2.so.0.63
#12 0x772891ca in rt.sections_linux.DSO.opApply() () from
/usr/lib/libphobos2.so.0.63
#13 0x772884ae in rt_moduleCtor () from
/usr/lib/libphobos2.so.0.63
#14 0x772818ad in rt.dmain2._d_run_main() () from
/usr/lib/libphobos2.so.0.63
#15 0x772813cd in rt.dmain2._d_run_main() () from
/usr/lib/libphobos2.so.0.63
#16 0x77281387 in _d_run_main () from
/usr/lib/libphobos2.so.0.63
#17 0x772811d4 in main () from /usr/lib/libphobos2.so.0.63
#18 0x7653ca15 in __libc_start_main () from
/usr/lib/libc.so.6
#19 0x0043f9d9 in _start ()
Unfortunately, no debugging symbols for phobos.
program was compiled with dmd (2.063) using the following flags:
-g -debug -unittest
Re: DMD 2.063 produces broken binaries
On Monday, 10 June 2013 at 18:50:21 UTC, Brandon wrote:
On Monday, 10 June 2013 at 16:52:51 UTC, Jerry wrote:
No, same problem. BTW, it's segfaulting in _d_dso_registry()
before
main() gets run.
4. If you make any other calls into the stdlib aside from
I/O, do they
work?
It doesn't matter. The following program segfaults:
void main() {}
5. Does gdb reveal anything interesting?
Unfortunately there's no debugging symbols in
_d_dso_registry(). I
assume the compiler is writing asm directly.
Jerry
I got a similar issue when upgrading to 2.063 on arch linux, so
I feel this may be relevant to the current problem. Heres the
backtrace for me.
#0 0x77286f54 in _d_arrayappendcd () from
/usr/lib/libphobos2.so.0.63
#1 0x7721f5c4 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#2 0x772781a2 in _aApplycd1 () from
/usr/lib/libphobos2.so.0.63
#3 0x7721f566 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#4 0x77278626 in _aApplycd2 () from
/usr/lib/libphobos2.so.0.63
#5 0x7721f4b5 in std.string.__T7toLowerTAyaZ.toLower()
() from /usr/lib/libphobos2.so.0.63
#6 0x771b4f15 in
std.encoding.EncodingScheme.register() () from
/usr/lib/libphobos2.so.0.63
#7 0x771b543a in
std.encoding.EncodingSchemeASCII._sharedStaticCtor9() ()
from /usr/lib/libphobos2.so.0.63
#8 0x771bb351 in std.encoding.__modsharedctor() ()
from /usr/lib/libphobos2.so.0.63
#9 0x77288c54 in rt.minfo.ModuleGroup.runCtors() ()
from /usr/lib/libphobos2.so.0.63
#10 0x77288196 in rt.minfo.ModuleGroup.runCtors() ()
from /usr/lib/libphobos2.so.0.63
#11 0x772884dd in rt.minfo.rt_moduleCtor() () from
/usr/lib/libphobos2.so.0.63
#12 0x772891ca in rt.sections_linux.DSO.opApply() ()
from /usr/lib/libphobos2.so.0.63
#13 0x772884ae in rt_moduleCtor () from
/usr/lib/libphobos2.so.0.63
#14 0x772818ad in rt.dmain2._d_run_main() () from
/usr/lib/libphobos2.so.0.63
#15 0x772813cd in rt.dmain2._d_run_main() () from
/usr/lib/libphobos2.so.0.63
#16 0x77281387 in _d_run_main () from
/usr/lib/libphobos2.so.0.63
#17 0x772811d4 in main () from
/usr/lib/libphobos2.so.0.63
#18 0x7653ca15 in __libc_start_main () from
/usr/lib/libc.so.6
#19 0x0043f9d9 in _start ()
Unfortunately, no debugging symbols for phobos.
program was compiled with dmd (2.063) using the following
flags: -g -debug -unittest
I suspected it may be the problem with shared libraries.
Can you try compiling that hello world with static libphobos?
Or can you attach your segfaulting binary?
Re: DMD 2.063 produces broken binaries
On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default.
Re: DMD 2.063 produces broken binaries
On Monday, 10 June 2013 at 21:33:20 UTC, Walter Bright wrote: On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default. Brandon's back-trace mentions libphobos2.so.0.63 OP's backtrace shows that SIGSEGV occurs in _d_dso_registry() My guess would be to check that first.
Re: DMD 2.063 produces broken binaries
On 6/10/2013 2:56 PM, Walter Bright wrote: On 6/10/2013 2:38 PM, nazriel wrote: On Monday, 10 June 2013 at 21:33:20 UTC, Walter Bright wrote: On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default. Brandon's back-trace mentions libphobos2.so.0.63 OP's backtrace shows that SIGSEGV occurs in _d_dso_registry() My guess would be to check that first. linking with -g -debug -unittest will statically link, it will not link with the .so One way to be sure - delete all the libphobos2.so files. All of them, then try again.
Re: DMD 2.063 produces broken binaries
On 6/10/2013 2:38 PM, nazriel wrote: On Monday, 10 June 2013 at 21:33:20 UTC, Walter Bright wrote: On 6/10/2013 2:28 PM, nazriel wrote: program was compiled with dmd (2.063) using the following flags: -g -debug -unittest I suspected it may be the problem with shared libraries. Can you try compiling that hello world with static libphobos? Or can you attach your segfaulting binary? Statically linking with libphobos2.a is the default. Brandon's back-trace mentions libphobos2.so.0.63 OP's backtrace shows that SIGSEGV occurs in _d_dso_registry() My guess would be to check that first. linking with -g -debug -unittest will statically link, it will not link with the .so
Re: DMD 2.063 produces broken binaries
Walter Bright writes:
> On 6/10/2013 2:56 PM, Walter Bright wrote:
>> On 6/10/2013 2:38 PM, nazriel wrote:
>>> On Monday, 10 June 2013 at 21:33:20 UTC, Walter Bright wrote:
On 6/10/2013 2:28 PM, nazriel wrote:
>> program was compiled with dmd (2.063) using the following flags: -g
>> -debug
>> -unittest
>
> I suspected it may be the problem with shared libraries.
> Can you try compiling that hello world with static libphobos?
> Or can you attach your segfaulting binary?
Statically linking with libphobos2.a is the default.
>>>
>>> Brandon's back-trace mentions libphobos2.so.0.63
His code appears to die after main() is in progress.
>>> OP's backtrace shows that SIGSEGV occurs in _d_dso_registry()
>>>
>>> My guess would be to check that first.
>>
>> linking with -g -debug -unittest will statically link, it will not link with
>> the
>> .so
Yes, strace on dmd shows that I'm linking with libphobos2.a.
...
[pid 23169] open("/home/jlquinn/dmd2/linux/bin64/../lib64/libphobos2.a",
O_RDONLY|O_CLOEXEC) = 11
Re: DMD 2.063 produces broken binaries
I just started having this problem as well, however it appears whether I'm using the latest DMD or older versions (I only tried as far back as 2.060). Like others, the program compiled with 2.063 dies at _d_dso_registry(). The programs compiled with previous versions die at gc_init(). I've made no other relevant changes recently, so I'm rather perplexed.
Re: DMD 2.063 produces broken binaries
On 6/10/2013 9:52 AM, Jerry wrote: 5. Does gdb reveal anything interesting? Unfortunately there's no debugging symbols in _d_dso_registry(). I assume the compiler is writing asm directly. Use the 'disassemble' command starting at _d_dso_registry, and point out which instruction is faulting. You might also try running the program under valgrind.
Re: DMD 2.063 produces broken binaries
On 6/9/2013 11:41 PM, Jerry wrote: LD_LIBRARY_PATH is empty. I've now reproduced this segfault on a Debian testing machine as well as my Ubuntu one. I'm pretty confused. LD_LIBRARY_PATH only applies to shared libraries.
Re: DMD 2.063 produces broken binaries
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.
Andrei
Re: DMD 2.063 produces broken binaries
Walter Bright writes: > On 6/10/2013 9:52 AM, Jerry wrote: >>> 5. Does gdb reveal anything interesting? >> >> Unfortunately there's no debugging symbols in _d_dso_registry(). I >> assume the compiler is writing asm directly. > > Use the 'disassemble' command starting at _d_dso_registry, and point out which > instruction is faulting. > > You might also try running the program under valgrind. Valgrind output followed by disassembly within gdb: jlquinn@wyvern:~/re/test$ valgrind ./junk ==24371== Memcheck, a memory error detector ==24371== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==24371== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==24371== Command: ./junk ==24371== ==24371== Invalid write of size 8 ==24371==at 0x4187B0: _d_dso_registry (in /home/jlquinn/re/test/junk) ==24371==by 0x4176B6: ??? (in /home/jlquinn/re/test/junk) ==24371==by 0x4302BC: __libc_csu_init (in /home/jlquinn/re/test/junk) ==24371==by 0x52786FF: (below main) (libc-start.c:185) ==24371== Address 0x105616130 is not stack'd, malloc'd or (recently) free'd ==24371== ==24371== ==24371== Process terminating with default action of signal 11 (SIGSEGV) ==24371== Access not within mapped region at address 0x105616130 ==24371==at 0x4187B0: _d_dso_registry (in /home/jlquinn/re/test/junk) ==24371==by 0x4176B6: ??? (in /home/jlquinn/re/test/junk) ==24371==by 0x4302BC: __libc_csu_init (in /home/jlquinn/re/test/junk) ==24371==by 0x52786FF: (below main) (libc-start.c:185) ==24371== If you believe this happened as a result of a stack ==24371== overflow in your program's main thread (unlikely but ==24371== possible), you can try to increase the size of the ==24371== main thread stack using the --main-stacksize= flag. ==24371== The main thread stack size used in this run was 8388608. ==24371== ==24371== HEAP SUMMARY: ==24371== in use at exit: 120 bytes in 3 blocks ==24371== total heap usage: 3 allocs, 0 frees, 120 bytes allocated ==24371== ==24371== LEAK SUMMARY: ==24371==definitely lost: 8 bytes in 1 blocks ==24371==indirectly lost: 0 bytes in 0 blocks ==24371== possibly lost: 0 bytes in 0 blocks ==24371==still reachable: 112 bytes in 2 blocks ==24371== suppressed: 0 bytes in 0 blocks ==24371== Rerun with --leak-check=full to see details of leaked memory ==24371== ==24371== For counts of detected and suppressed errors, rerun with: -v ==24371== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Segmentation fault (core dumped) Program received signal SIGSEGV, Segmentation fault. 0x004187b0 in _d_dso_registry () (gdb) disassemble Dump of assembler code for function _d_dso_registry: 0x004185b0 <+0>: push %rbp 0x004185b1 <+1>: mov%rsp,%rbp 0x004185b4 <+4>: sub$0x98,%rsp 0x004185bb <+11>:push %rbx 0x004185bc <+12>:push %r12 0x004185be <+14>:push %r13 0x004185c0 <+16>:push %r14 0x004185c2 <+18>:push %r15 0x004185c4 <+20>:mov%rdi,%r12 0x004185c7 <+23>:movabs $0x1,%rax 0x004185d1 <+33>:cmp%rax,(%r12) 0x004185d5 <+37>:jae0x4185d8 <_d_dso_registry+40> 0x004185d7 <+39>:hlt 0x004185d8 <+40>:mov0x8(%r12),%rcx 0x004185dd <+45>:cmpq $0x0,(%rcx) 0x004185e1 <+49>:jne0x4187b6 <_d_dso_registry+518> 0x004185e7 <+55>:movabs $0x60,%rsi 0x004185f1 <+65>:mov%rax,%rdi 0x004185f4 <+68>:callq 0x417220 0x004185f9 <+73>:mov%rax,%r14 0x004185fc <+76>:mov0x8(%r12),%rdx 0x00418601 <+81>:mov%r14,(%rdx) ---Type to continue, or q to quit--- 0x00418604 <+84>:lea-0x70(%rbp),%rax 0x00418608 <+88>:xor%rcx,%rcx 0x0041860b <+91>:mov%rcx,(%rax) 0x0041860e <+94>:mov%rcx,0x8(%rax) 0x00418612 <+98>:mov%rcx,0x10(%rax) 0x00418616 <+102>: mov%rcx,0x18(%rax) 0x0041861a <+106>: mov%rcx,0x20(%rax) 0x0041861e <+110>: mov%rcx,0x28(%rax) 0x00418622 <+114>: mov0x18(%r12),%rax 0x00418627 <+119>: mov0x10(%r12),%rbx 0x0041862c <+124>: sub%rbx,%rax 0x0041862f <+127>: cqto 0x00418631 <+129>: and$0x7,%rdx 0x00418638 <+136>: add%rdx,%rax 0x0041863b <+139>: sar$0x3,%rax 0x0041863f <+143>: mov%rbx,%rdx 0x00418642 <+146>: mov%rax,-0x70(%rbp) 0x00418646 <+150>: mov%rdx,-0x68(%rbp) 0x0041864a <+154>: lea-0x70(%rbp),%rsi 0x0041864e <+158>: lea0x10(%r14),%rdi 0x00418652 <+162>: movsq %ds:(%rsi),%es:(%rdi) 0x00418654 <+164>:
Re: DMD 2.063 produces broken binaries
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
Re: DMD 2.063 produces broken binaries
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? ;)
Re: DMD 2.063 produces broken binaries
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
Re: DMD 2.063 produces broken binaries
"nazriel" 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
Re: DMD 2.063 produces broken binaries
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" 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: => 0x004187b0 <+512>: movQWORD PTR [rax-0x8],r14 I created an breakpoint at 1 instruction before the one mentioned above. Reg info: Breakpoint 1, 0x004187ac in _d_dso_registry () (gdb) info reg rax0x43d0a0 320 rbx0x1 1 rcx0x10043d0a0 4299411616 rdx0x43d0a0 320 rsi0x0 0 rdi0x4 4 rbp0x7fffe8d0 0x7fffe8d0 rsp0x7fffe810 0x7fffe810 r8 0x3 3 r9 0x7fffe760 140737488349024 r100x7fffe5a0 140737488348576 r110x77686320 140737344201504 r120x400270 4194928 r130x43d050 240 r140x43d010 176 r150x1 1 rip0x4187ac 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: movrbx,QWORD PTR [rip+0x247b30]# 0x680808 <_D2rt14sections_linux12_static_dsosS2rt4util9container36__T5ArrayTPS2rt14sections_linux3DSOZ5Array+8> Borked one: movrbx,QWORD PTR [rip+0x2359c]# 0x43bd24 <_D2rt14sections_linux12_static_dsosS2rt4util9container36__T5ArrayTPS2rt14sections_linux3DSOZ5Array+4> See the 4 vs 8 offset
