Hi,
I have dmd version 2.048, OS X 10.5.8
If I compile this :
import std.stdio;
int main()
{
writefln("%d",0);
return 0;
}
with "dmd file.d"
and then run it
I get segmentation fault in writefln
if I then compile this :
import std.stdio;
int x;
int main()
{
writefln("%d",0);
return 0;
}
and run it, it works.
Comment #1 by wresch — 2010-10-15T16:51:44Z
I have the exact same issue. In the code below the segfault happens in writefln.
Setup:
Digital Mars D Compiler v2.049
OS X 10.5.3
2.26 MHz Core2 duo (macbook pro)
[510]dmd2 > cat hello.d
import std.stdio;
//int x;
void main() {
writeln("hello world!");
writefln("foo = %d", 10);
}
[511]dmd2 > ./hello
Segmentation fault
[515]dmd2 > cat hello2.d
import std.stdio;
int x;
void main() {
writeln("hello world!");
writefln("foo = %d", 10);
}
[
[514]dmd2 > ./hello2
hello world!
foo = 10
Comment #2 by garfieldrules — 2010-10-15T17:04:55Z
I have the same problem. In my OS X 10.5.8 installation, any program in my with a writef or writefln statement in DMD >= 2.047 segfaults. Oddly, this problem is NOT present in DMD 2.046. Readf in >= 2.047 also causes trouble.
Comment #3 by garfieldrules — 2010-10-15T17:08:27Z
My setup:
Digital Mars D 2.049
OS X 10.5.8
MacBook Black early 2008
Core 2 Duo 2.4ghz
Comment #4 by clugdbug — 2010-11-07T13:51:01Z
Can somebody please help to track this down further?
Does it crash with: import std.stdio; void main() { writeln("abc", 0);} ?
Does it crash with: import std.string; void main() { format("%d", 0); } ?
Does it crash with: import std.string; void main() { writefln("abc"); } ?
If it crashes with writeln, it's probably a compiler code generation bug, related to varargs.
And can you get a stack trace?
Comment #5 by alexibu — 2010-11-08T01:51:46Z
(In reply to comment #4)
> Can somebody please help to track this down further?
> Does it crash with: import std.stdio; void main() { writeln("abc", 0);} ?
YES
> Does it crash with: import std.string; void main() { format("%d", 0); } ?
NO
> Does it crash with: import std.string; void main() { writefln("abc"); } ?
assume you meant import std.stdio: YES
>
> If it crashes with writeln, it's probably a compiler code generation bug,
> related to varargs.
>
> And can you get a stack trace?
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x00000000
0x0000a7b9 in __tls_get_addr ()
(gdb) bt
#0 0x0000a7b9 in __tls_get_addr ()
#1 0x000073a1 in _moduleTlsCtor ()
#2 0x0000fbfd in D2rt6dmain24mainUiPPaZi6runAllMFZv ()
#3 0x0000fb06 in D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv ()
#4 0x0000fa93 in main ()
Comment #6 by bugzilla — 2010-11-08T09:59:18Z
I cannot reproduce this problem with OS X 10.6.
Comment #7 by doob — 2010-11-08T12:34:49Z
I can reproduce it on Mac OS X 10.5.8 using dmd 2.050.
Comment #8 by bugzilla — 2010-11-08T14:11:18Z
I've had a lot of problems with the 10.5 linker screwing up on empty sections. I suspect the solution is for, a module that defines main(), to output 4 bytes of dummy data into the tls section if it is blank.
Comment #9 by nfxjfg — 2010-11-08T14:19:29Z
I'm curious: why you need to rely on (obviously) not guaranteed linker behaviour?
Btw. gcc supports TLS variables via extensions, if that is the problem.
Comment #10 by doob — 2010-11-09T00:09:39Z
TLS is not supported by GCC on Mac OS X.
Comment #11 by doob — 2010-11-20T03:14:21Z
Created attachment 823
Patch
I'm adding my patch here as well so it doesn't get lost.
I've created a patch but I'm not completely sure if it solves the problem or not. I don't get an error in __tls_get_addr now but instead I get this:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x97655133 in strncmp ()
(gdb) bt
#0 0x97655133 in strncmp ()
#1 0x0000101c in ?? ()
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb)
Maybe someone else can look at the patch and see if I did something wrong or maybe the solution we thought of couldn't fix the problem.
Comment #12 by andrei — 2012-01-31T14:57:11Z
Can this be still reproduced? The code works for me on OSX 10.7.2.
Comment #13 by doob — 2012-01-31T23:32:45Z
(In reply to comment #12)
> Can this be still reproduced? The code works for me on OSX 10.7.2.
As the title say, it's only for Mac OS X 10.5.
Comment #14 by bugzilla — 2012-02-06T19:58:16Z
Is anyone still running 10.5? That's two OSX versions ago.
Comment #15 by doob — 2012-02-07T04:21:38Z
I (In reply to comment #14)
> Is anyone still running 10.5? That's two OSX versions ago.
I don't know. But I see now reason why we shouldn't support 10.5 as long as it doesn't cause too much problem. We're still supporting Windows XP which is two versions ago as well and is far older than Mac OS X 10.5. And yes, I know you can't really compare Mac OS X and Windows in this case.
Comment #16 by github-bugzilla — 2012-03-07T18:33:23Z