www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11149] New: Runtime.args no longer available in static constructors.

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149

           Summary: Runtime.args no longer available in static
                    constructors.
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: druntime
        AssignedTo: nobody puremagic.com
        ReportedBy: mike-wey planet.nl



With git head/2.064 core.runtime.Runtime.args always returns null when called
from a static constructor, with 2.063 it used to return the commandline args.

Calling it from main works in both versions.

----
import core.runtime;

string[] test;

shared static this()
{
    test = Runtime.args;
}

void main()
{
    assert(test !is null);
}
----
The assert fails with git head/2.064.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 30 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



04:36:46 PDT ---
Any platform details?

I can't reproduce this on Win7 (using -m32) with these recent commits:

dmd: e0a201bbf80fb7bfbc7e5caf2c29921c3bddf5e3
druntime: 12d535030de97835b4c2fb96d079942d93ea708e
phobos: d744bec6d4500d6cb6f43011beefc7765dd0e5ce

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 01 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Mike Wey <mike-wey planet.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|All                         |Linux



Linux, both 64 and 32 bits.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 01 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |WORKSFORME



02:17:05 PDT ---
This is working for me with dmd 2.064 head.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




05:36:04 PDT ---

 This is working for me with dmd 2.064 head.
On Linux? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code dawg.eu



*** Issue 11191 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |



This is a regression caused by moving the module initialization into C's
.ctor/.dtor sections.
Not sure how to resolve this right now.

BTW, I don't that adding args/cArgs was a good idea in the first place.
They provide global access to mutable data but the exact semantics remain
unclear, e.g. how is mutating args reflected in main's args and vice versa.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




10:20:03 PDT ---

 BTW, I don't that adding args/cArgs was a good idea in the first place.
Some libraries require the C arguments during initialization routines. If you try to initialize such a library in a module constructor then core.runtime is the only way of getting to the main() arguments.
 how is mutating args reflected in main's args and vice versa.
It's not reflected since a copy is made in _d_run_main. But I guess this should be documented. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|nobody puremagic.com        |code dawg.eu




 It's not reflected since a copy is made in _d_run_main. But I guess this should
 be documented.
The arguments are not copied.
 This is a regression caused by moving the module initialization into C's
.ctor/.dtor sections. Other than poking around in glibc's internals we can only resolve this issue by delaying D's initialization until C's main again. I'll look into this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




07:26:55 PDT ---


 It's not reflected since a copy is made in _d_run_main. But I guess this should
 be documented.
The arguments are not copied.
I'm not seeing that: ----- import core.runtime; import std.stdio; import std.string; void main(char[][] args) { auto c_args = Runtime.cArgs; printf("%s\n", c_args.argv[0]); c_args.argv[0] = cast(char*)("foobar\0".dup.ptr); printf("%s\n", c_args.argv[0]); writeln(args[0]); } ----- $ rdmd test.d
 C:\Users\ADMINI~1\AppData\Local\Temp\.rdmd\rdmd-test.d-E4AFE2A9EC3418A8D53133284F27D58A\test.exe
 foobar
 C:\Users\ADMINI~1\AppData\Local\Temp\.rdmd\rdmd-test.d-E4AFE2A9EC3418A8D53133284F27D58A\test.exe
-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149





 The arguments are not copied.
I'm not seeing that:
Yes, the C args are copied to the D args. But the C args themselves are not copied. If you run a custom C main this might cause problems but that is a programming error we don't need to fix. Another problem is when you have a C program that links against a D library, we don't have access to main's arguments here. Same issue for shared libraries where providing access to main arguments hardly makes sense. I'm a bit annoyed by this issue because it's so obviously wrong to provide global access to main's arguments before main gets called. If someone wanted global access they could just copy the arguments into a global variable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 17 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




06:58:53 PDT ---


 The arguments are not copied.
I'm not seeing that:
Yes, the C args are copied to the D args. But the C args themselves are not copied. If you run a custom C main this might cause problems but that is a programming error we don't need to fix.
But C libraries probably already expect this behavior. That's the only thing cArgs is for really, to interface with those C libs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 18 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




14:25:36 PDT ---
Martin, what do we do about this one?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149





 Martin, what do we do about this one?
I don't know yet but try to find a solution as soon as I have time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Jacob Carlborg <doob me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob me.com





 I don't know yet but try to find a solution as soon as I have time.
Could you read /proc/self/cmdline ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149





 I don't know yet but try to find a solution as soon as I have time.
Could you read /proc/self/cmdline ?
Thanks for the idea Jacob. It would solve the regression but it's not portable. So once we port the shared library bits to FreeBSD/OSX it will break on those platforms. NB: Shared libraries were the reason to move the init/fini calls. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149






 Thanks for the idea Jacob. It would solve the regression but it's not portable.
 So once we port the shared library bits to FreeBSD/OSX it will break on those
 platforms.
 
 NB: Shared libraries were the reason to move the init/fini calls.
None of this low level stuff is portable. FreeBSD: using sysctl with KERN_PROC_ARGS looks like it would to the trick. See: http://www.freebsd.org/cgi/man.cgi?query=sysctl&sektion=3&apropos=0&manpath=FreeBSD+9.2-RELEASE https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L1650 Mac OS X: _NSGetArgv and _NSGetArgc. See /usr/include/crt_externs.h. Windows (if needed): GetCommandLine. See: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683156.aspx -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


9999 <mailnew4ster gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mailnew4ster gmail.com



For Windows there's also CommandLineToArgvW.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




Thanks, that should work indeed.
There is at least another regression due to the implicit init/fini of druntime
(bug 11309).
So I'll fix this and the other bug by make the initialization of shared D
libraries explicit. There are a few more reasons for this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




BWT, I forgot to mention this. If I recall correctly,_NSGetArgv and _NSGetArgc
are private functions. That means, they are not allowed in sandboxed
applications, that is, applications in App Store, both on Mac OS X and iOS. I
don't know if this is something we would like to care about. On the other hand
we already use _NSGetEnviron in std.process. But all of these are mentioned in
the documentation of NSApplicationMain, here:

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Miscellaneous/AppKit_Functions/Reference/reference.html#//apple_ref/c/func/NSApplicationMain

Question, how is the runtime initialized now? I mean, is it initialized in a
shared module constructor?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149





 Question, how is the runtime initialized now? I mean, is it initialized in a
 shared module constructor?
At least on linux it is done from .ctor/.dtor functions that call _d_dso_registry. This is the similar to __attribute__((constructor))/__attribute__((destructor)) functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149





 At least on linux it is done from .ctor/.dtor functions that call
 _d_dso_registry.
 This is the similar to __attribute__((constructor))/__attribute__((destructor))
 functions.
How does the compiler make sure that the .ctor that initializes the runtime is run before any user shared module constructors? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




13:41:20 PDT ---
I'd like to get 2.064 release finalized. That means this regression needs to be
fixed, or deferred. What do you guys think?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




Another idea that could work is to not use .ctor for the shared module
constructors, as before. Then have a single .ctor that initializes the runtime.
The shared module constructors would be run from C main/rt_init as before.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149





 I'd like to get 2.064 release finalized. That means this regression needs to be
 fixed, or deferred. What do you guys think?
We can't defer it, because it has too much impact IMO. For example vibe.d uses Runtime.args to process command line arguments. There are probably more tools taking this approach all of which would break. I filed the underlying issue as bug 11378 and currently work on a fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




13:19:10 PDT ---

 I filed the underlying issue as bug 11378 and currently work on a fix.
Thank you! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149




Commit pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/d3c89cf1894aefa884303344a18436841eae0744
fix Issue 11149 - Runtime.args no longer available in static constructor

- This got fixed by reverting the order of initialization.
- Add unittest

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11149


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 30 2013