Bug 4854 – Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no globals

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Mac OS X
Creation time
2010-09-11T14:29:00Z
Last change time
2012-03-07T18:34:28Z
Assigned to
nobody
Creator
alexibu

Attachments

IDFilenameSummaryContent-TypeSize
823osx.patchPatchtext/plain10120

Comments

Comment #0 by alexibu — 2010-09-11T14:29:49Z
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
Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/73cf2c150665cb17d9365a6e3d6cf144d76312d6 fix Issue 4854 - Regression(2.047, Mac 10.5 only) writefln Segmentation fault if no globals
Comment #17 by bugzilla — 2012-03-07T18:34:28Z
I don't have 10.5 to test it on, but this should fix it.