From keith.amling at gmail.com Mon May 8 20:21:54 2017 From: keith.amling at gmail.com (Keith Amling) Date: Mon, 8 May 2017 13:21:54 -0700 Subject: Compiler bug with nested lambdas and anonymous inner classes? Message-ID: <20170508202154.GH21050@gmail.com> > $ cat Bug.java > public class Bug { > public static void foo() { > Runnable r1 = () -> { > new Object() { > Runnable r2 = () -> new Object() { }; > }; > }; > } > } > $ "Compiles", but bytecode is nonsense (generates aload_0 in static method with no args) and fails verification: > $ javac Bug.java > $ javap -private -c -verbose Bug | grep 'foo()' -A 12 > public static void foo(); > descriptor: ()V > flags: ACC_PUBLIC, ACC_STATIC > Code: > stack=1, locals=1, args_size=0 > 0: aload_0 > 1: invokedynamic #2, 0 // InvokeDynamic #0:run:(LBug;)Ljava/lang/Runnable; > 6: astore_0 > 7: return > LineNumberTable: > line 3: 0 > line 8: 7 > > $ java Bug > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.lang.VerifyError: Bad local variable type > Exception Details: > Location: > Bug.foo()V @0: aload_0 > Reason: > Type top (current frame, locals[0]) is not assignable to reference type > Current Frame: > bci: @0 > flags: { } > locals: { } > stack: { } > Bytecode: > 0x0000000: 2aba 0002 0000 4bb1 > > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) > at java.lang.Class.privateGetMethodRecursive(Class.java:3048) > at java.lang.Class.getMethod0(Class.java:3018) > at java.lang.Class.getMethod(Class.java:1784) > at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) > at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) > $ This with: > $ uname -a > Linux trtoje 4.9.0-2-amd64 #1 SMP Debian 4.9.10-1 (2017-02-17) x86_64 GNU/Linux > $ java -version > openjdk version "1.8.0_131" > OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1-b11) > OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode) > $ Keith From david.holmes at oracle.com Tue May 9 01:05:16 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 May 2017 11:05:16 +1000 Subject: Compiler bug with nested lambdas and anonymous inner classes? In-Reply-To: <20170508202154.GH21050@gmail.com> References: <20170508202154.GH21050@gmail.com> Message-ID: Hi Keith, Thanks - bug reports can be made at http://bugreport.java.com/ Or you could discuss this issue with javac folk via compiler-dev at openjdk.java.net (cc'd). This issue is fixed in JDK 9 but still present in JDK 8u. Please drop the discuss list from any replies. Thanks, David On 9/05/2017 6:21 AM, Keith Amling wrote: >> $ cat Bug.java >> public class Bug { >> public static void foo() { >> Runnable r1 = () -> { >> new Object() { >> Runnable r2 = () -> new Object() { }; >> }; >> }; >> } >> } >> $ > > "Compiles", but bytecode is nonsense (generates aload_0 in static method with > no args) and fails verification: > >> $ javac Bug.java >> $ javap -private -c -verbose Bug | grep 'foo()' -A 12 >> public static void foo(); >> descriptor: ()V >> flags: ACC_PUBLIC, ACC_STATIC >> Code: >> stack=1, locals=1, args_size=0 >> 0: aload_0 >> 1: invokedynamic #2, 0 // InvokeDynamic #0:run:(LBug;)Ljava/lang/Runnable; >> 6: astore_0 >> 7: return >> LineNumberTable: >> line 3: 0 >> line 8: 7 >> >> $ java Bug >> Error: A JNI error has occurred, please check your installation and try again >> Exception in thread "main" java.lang.VerifyError: Bad local variable type >> Exception Details: >> Location: >> Bug.foo()V @0: aload_0 >> Reason: >> Type top (current frame, locals[0]) is not assignable to reference type >> Current Frame: >> bci: @0 >> flags: { } >> locals: { } >> stack: { } >> Bytecode: >> 0x0000000: 2aba 0002 0000 4bb1 >> >> at java.lang.Class.getDeclaredMethods0(Native Method) >> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) >> at java.lang.Class.privateGetMethodRecursive(Class.java:3048) >> at java.lang.Class.getMethod0(Class.java:3018) >> at java.lang.Class.getMethod(Class.java:1784) >> at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) >> at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) >> $ > > This with: > >> $ uname -a >> Linux trtoje 4.9.0-2-amd64 #1 SMP Debian 4.9.10-1 (2017-02-17) x86_64 GNU/Linux >> $ java -version >> openjdk version "1.8.0_131" >> OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1-b11) >> OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode) >> $ > > Keith > From pierre at 2bst.fr Wed May 10 11:48:05 2017 From: pierre at 2bst.fr (=?utf-8?q?pierre=402bst=2Efr?=) Date: Wed, 10 May 2017 13:48:05 +0200 Subject: Environment variables truth source of the JVM =?utf-8?q?=28and?= how to mutate =?utf-8?q?it=29?= Message-ID: <6383-5912fe00-27-2c82f7c0@208121580> Hi, I've been trying to understand how the JVM accesses environment variables and how they can be mutated. For this I've made some assumptions and I would like to know if they're correct, could you help me on this? :-) * It appears that the JVM gets a copy of its process environment variables and store them in static final fields theUnmodifiableEnvironment and theEnvironment of class java.lang.ProcessEnvironment. * My assumption is: these fields are the "truth source" about environment variables inside the JVM and any attempt to access some of them will end up in a lookup of this fields. * I have a question about this: why two final fields instead of only one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst theEnvironment is for env of current process (which could be changed with Process.exec(String[] cmdarray, String[] envp, File dir))? * There is a subtle way to mutate them in Sun JDK (see http://www.javaspecialists.eu/archive/Issue161.html). * My assumption is: These fields are passed to all new JVM threads, so mutating them (as ugly as it can sound) will be JVM-wide and will result in all thread getting mutated env as their environment variables. * Sensitive question: is this enforced? System.getenv() appears to correctly returns mutated env, can I deduce all new threads in the JVM will get mutated values? * Another sensitive question: as these fields are static final, can I deduce all threads in the JVM will get mutated values, not only new ones?It would be my pleasure to provide further details ifneedsbe. Just let me know if some of the above assumptions are incorrect! Yours faithfully, p2b From pierre at 2bst.fr Wed May 10 11:55:23 2017 From: pierre at 2bst.fr (=?utf-8?q?pierre=402bst=2Efr?=) Date: Wed, 10 May 2017 13:55:23 +0200 Subject: Environment variables truth source of the JVM =?utf-8?q?=28and?= how to mutate =?utf-8?q?it=29?= Message-ID: <6383-5912ff80-2f-2c82f7c0@208121712> Hi, I've been trying to understand how the JVM accesses environment variables and how they can be mutated. I sent an email on this list few minutes ago but it appears to be ill-formatted and hardly legible. Sorry for double post: I resend it with better formatting hopefully. For this I've made some assumptions and I would like to know if they're correct, could you help me on this? 1) It appears that the JVM gets a copy of its process environment variables and store them in static final fields theUnmodifiableEnvironment and theEnvironment of class java.lang.ProcessEnvironment. - My assumption is: these fields are the "truth source" about ? environment variables inside the JVM and any attempt to access some of ? them will end up in a lookup of this fields. - I have a question about this: why two final fields instead of only ? one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst ? theEnvironment is for env of current process (which could be changed ? with Process.exec(String[] cmdarray, String[] envp, File dir))? 2) There is a subtle way to mutate them in Sun JDK (see http://www.javaspecialists.eu/archive/Issue161.html). - My assumption is: These fields are passed to all new JVM threads, so ? mutating them (as ugly as it can sound) will be JVM-wide and will ? result in all thread getting mutated env as their environment ? variables. ? - Sensitive question: is this enforced? System.getenv() appears to ? correctly returns mutated env, can I deduce all new threads in the JVM ? will get mutated values? ? - Another sensitive question: as these fields are static final, can I ? deduce all threads in the JVM will get mutated values, not only new ? ones? It would be my pleasure to provide further details ifneedsbe. Just let me know if some of the above assumptions are incorrect! Again, please forgive that double post. Yours faithfully, p2b From martijnverburg at gmail.com Wed May 10 13:08:18 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 10 May 2017 14:08:18 +0100 Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: <6383-5912ff80-2f-2c82f7c0@208121712> References: <6383-5912ff80-2f-2c82f7c0@208121712> Message-ID: Hi Pierre, Welcome to OpenJDK! This question is best asked over on the core-libs-dev mailing list. This mailing list is more for general discussions about the community itself. Cheers, Martijn On 10 May 2017 at 12:55, pierre at 2bst.fr wrote: > > Hi, I've been trying to understand how the JVM accesses environment > variables and how they can be mutated. > > I sent an email on this list few minutes ago but it appears to be > ill-formatted and hardly legible. Sorry for double post: I resend it > with better formatting hopefully. > > For this I've made some assumptions and I would like to know if they're > correct, could you help me on this? > > 1) It appears that the JVM gets a copy of its process environment > variables and store them in static final fields > theUnmodifiableEnvironment and theEnvironment of class > java.lang.ProcessEnvironment. > > - My assumption is: these fields are the "truth source" about > environment variables inside the JVM and any attempt to access some of > them will end up in a lookup of this fields. > > - I have a question about this: why two final fields instead of only > one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst > theEnvironment is for env of current process (which could be changed > with Process.exec(String[] cmdarray, String[] envp, File dir))? > > 2) There is a subtle way to mutate them in Sun JDK (see > http://www.javaspecialists.eu/archive/Issue161.html). > > - My assumption is: These fields are passed to all new JVM threads, so > mutating them (as ugly as it can sound) will be JVM-wide and will > result in all thread getting mutated env as their environment > variables. > > - Sensitive question: is this enforced? System.getenv() appears to > correctly returns mutated env, can I deduce all new threads in the JVM > will get mutated values? > > - Another sensitive question: as these fields are static final, can I > deduce all threads in the JVM will get mutated values, not only new > ones? > > It would be my pleasure to provide further details ifneedsbe. Just let > me know if some of the above assumptions are incorrect! Again, please > forgive that double post. > > Yours faithfully, > > p2b > From forax at univ-mlv.fr Wed May 10 13:32:09 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 10 May 2017 15:32:09 +0200 (CEST) Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: <6383-5912ff80-2f-2c82f7c0@208121712> References: <6383-5912ff80-2f-2c82f7c0@208121712> Message-ID: <1273998506.1456873.1494423129704.JavaMail.zimbra@u-pem.fr> Hi Pierre, it's more a question for the core-dev mailing list. The trick shown by Heinz does not work anymore with jdk 9. You can not mutate the environment variables of jdk, i repeat YOU CAN NOT MUTATE THE ENVIRONMENT VARIABLES OF THE JDK :) But you can send a new environment each time you create a new process, Using ProcessBuilder.environment(). cheers, R?mi ----- Mail original ----- > De: pierre at 2bst.fr > ?: discuss at openjdk.java.net > Envoy?: Mercredi 10 Mai 2017 13:55:23 > Objet: Environment variables truth source of the JVM (and how to mutate it) > Hi, I've been trying to understand how the JVM accesses environment > variables and how they can be mutated. > > I sent an email on this list few minutes ago but it appears to be > ill-formatted and hardly legible. Sorry for double post: I resend it > with better formatting hopefully. > > For this I've made some assumptions and I would like to know if they're > correct, could you help me on this? > > 1) It appears that the JVM gets a copy of its process environment > variables and store them in static final fields > theUnmodifiableEnvironment and theEnvironment of class > java.lang.ProcessEnvironment. > > - My assumption is: these fields are the "truth source" about >? environment variables inside the JVM and any attempt to access some of >? them will end up in a lookup of this fields. > > - I have a question about this: why two final fields instead of only >? one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst >? theEnvironment is for env of current process (which could be changed >? with Process.exec(String[] cmdarray, String[] envp, File dir))? > > 2) There is a subtle way to mutate them in Sun JDK (see > http://www.javaspecialists.eu/archive/Issue161.html). > > - My assumption is: These fields are passed to all new JVM threads, so >? mutating them (as ugly as it can sound) will be JVM-wide and will >? result in all thread getting mutated env as their environment >? variables. >? > - Sensitive question: is this enforced? System.getenv() appears to >? correctly returns mutated env, can I deduce all new threads in the JVM >? will get mutated values? >? > - Another sensitive question: as these fields are static final, can I >? deduce all threads in the JVM will get mutated values, not only new >? ones? > > It would be my pleasure to provide further details ifneedsbe. Just let > me know if some of the above assumptions are incorrect! Again, please > forgive that double post. > > Yours faithfully, > > p2b From pierre at 2bst.fr Wed May 10 13:52:22 2017 From: pierre at 2bst.fr (=?utf-8?q?pierre=402bst=2Efr?=) Date: Wed, 10 May 2017 15:52:22 +0200 Subject: =?utf-8?q?Re=3A?= Environment variables truth source of the JVM =?utf-8?q?=28and?= how to mutate =?utf-8?q?it=29?= In-Reply-To: <1273998506.1456873.1494423129704.JavaMail.zimbra@u-pem.fr> Message-ID: <68fd-59131b00-b-4fcbb200@23121556> Thanks for pointing ProcessBuilder.environment. So, as Java 9 moved to better accessibility policy enforcement, could it exist a way to set a default ProcessBuilder for all created processes of a JVM? On Wednesday, May 10, 2017 15:32 CEST, Remi Forax wrote: ?Hi Pierre, it's more a question for the core-dev mailing list. The trick shown by Heinz does not work anymore with jdk 9. You can not mutate the environment variables of jdk, i repeat YOU CAN NOT MUTATE THE ENVIRONMENT VARIABLES OF THE JDK :) But you can send a new environment each time you create a new process, Using ProcessBuilder.environment(). cheers, R?mi ----- Mail original ----- > De: pierre at 2bst.fr > ?: discuss at openjdk.java.net > Envoy?: Mercredi 10 Mai 2017 13:55:23 > Objet: Environment variables truth source of the JVM (and how to mutate it) > Hi, I've been trying to understand how the JVM accesses environment > variables and how they can be mutated. > > I sent an email on this list few minutes ago but it appears to be > ill-formatted and hardly legible. Sorry for double post: I resend it > with better formatting hopefully. > > For this I've made some assumptions and I would like to know if they're > correct, could you help me on this? > > 1) It appears that the JVM gets a copy of its process environment > variables and store them in static final fields > theUnmodifiableEnvironment and theEnvironment of class > java.lang.ProcessEnvironment. > > - My assumption is: these fields are the "truth source" about >? environment variables inside the JVM and any attempt to access some of >? them will end up in a lookup of this fields. > > - I have a question about this: why two final fields instead of only >? one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst >? theEnvironment is for env of current process (which could be changed >? with Process.exec(String[] cmdarray, String[] envp, File dir))? > > 2) There is a subtle way to mutate them in Sun JDK (see > http://www.javaspecialists.eu/archive/Issue161.html). > > - My assumption is: These fields are passed to all new JVM threads, so >? mutating them (as ugly as it can sound) will be JVM-wide and will >? result in all thread getting mutated env as their environment >? variables. >? > - Sensitive question: is this enforced? System.getenv() appears to >? correctly returns mutated env, can I deduce all new threads in the JVM >? will get mutated values? >? > - Another sensitive question: as these fields are static final, can I >? deduce all threads in the JVM will get mutated values, not only new >? ones? > > It would be my pleasure to provide further details ifneedsbe. Just let > me know if some of the above assumptions are incorrect! Again, please > forgive that double post. > > Yours faithfully, > > p2b ? From dalibor.topic at oracle.com Wed May 10 14:39:23 2017 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 10 May 2017 16:39:23 +0200 Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: <1273998506.1456873.1494423129704.JavaMail.zimbra@u-pem.fr> References: <6383-5912ff80-2f-2c82f7c0@208121712> <1273998506.1456873.1494423129704.JavaMail.zimbra@u-pem.fr> Message-ID: Yeah, you should not mutate the environment variables of any multi threaded application once it's running. I don't recall if the result was undefined or unspecified behavior, but it was unreliable behavior in any case. Cheers, Dalibor Topi? -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment > On 10. May 2017, at 15:32, Remi Forax wrote: > > Hi Pierre, > it's more a question for the core-dev mailing list. > > The trick shown by Heinz does not work anymore with jdk 9. > > You can not mutate the environment variables of jdk, > i repeat YOU CAN NOT MUTATE THE ENVIRONMENT VARIABLES OF THE JDK :) > > But you can send a new environment each time you create a new process, > Using ProcessBuilder.environment(). > > cheers, > R?mi > > ----- Mail original ----- >> De: pierre at 2bst.fr >> ?: discuss at openjdk.java.net >> Envoy?: Mercredi 10 Mai 2017 13:55:23 >> Objet: Environment variables truth source of the JVM (and how to mutate it) > >> Hi, I've been trying to understand how the JVM accesses environment >> variables and how they can be mutated. >> >> I sent an email on this list few minutes ago but it appears to be >> ill-formatted and hardly legible. Sorry for double post: I resend it >> with better formatting hopefully. >> >> For this I've made some assumptions and I would like to know if they're >> correct, could you help me on this? >> >> 1) It appears that the JVM gets a copy of its process environment >> variables and store them in static final fields >> theUnmodifiableEnvironment and theEnvironment of class >> java.lang.ProcessEnvironment. >> >> - My assumption is: these fields are the "truth source" about >> environment variables inside the JVM and any attempt to access some of >> them will end up in a lookup of this fields. >> >> - I have a question about this: why two final fields instead of only >> one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst >> theEnvironment is for env of current process (which could be changed >> with Process.exec(String[] cmdarray, String[] envp, File dir))? >> >> 2) There is a subtle way to mutate them in Sun JDK (see >> http://www.javaspecialists.eu/archive/Issue161.html). >> >> - My assumption is: These fields are passed to all new JVM threads, so >> mutating them (as ugly as it can sound) will be JVM-wide and will >> result in all thread getting mutated env as their environment >> variables. >> >> - Sensitive question: is this enforced? System.getenv() appears to >> correctly returns mutated env, can I deduce all new threads in the JVM >> will get mutated values? >> >> - Another sensitive question: as these fields are static final, can I >> deduce all threads in the JVM will get mutated values, not only new >> ones? >> >> It would be my pleasure to provide further details ifneedsbe. Just let >> me know if some of the above assumptions are incorrect! Again, please >> forgive that double post. >> >> Yours faithfully, >> >> p2b From martinrb at google.com Wed May 10 15:40:20 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 May 2017 08:40:20 -0700 Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: References: <6383-5912ff80-2f-2c82f7c0@208121712> <1273998506.1456873.1494423129704.JavaMail.zimbra@u-pem.fr> Message-ID: Crashes due to thread-unsafety of putenv/getenv are observed in the wild! On Wed, May 10, 2017 at 7:39 AM, Dalibor Topic wrote: > Yeah, you should not mutate the environment variables of any multi > threaded application once it's running. I don't recall if the result was > undefined or unspecified behavior, but it was unreliable behavior in any > case. > > Cheers, > Dalibor Topi? > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > On 10. May 2017, at 15:32, Remi Forax wrote: > > > > Hi Pierre, > > it's more a question for the core-dev mailing list. > > > > The trick shown by Heinz does not work anymore with jdk 9. > > > > You can not mutate the environment variables of jdk, > > i repeat YOU CAN NOT MUTATE THE ENVIRONMENT VARIABLES OF THE JDK :) > > > > But you can send a new environment each time you create a new process, > > Using ProcessBuilder.environment(). > > > > cheers, > > R?mi > > > > ----- Mail original ----- > >> De: pierre at 2bst.fr > >> ?: discuss at openjdk.java.net > >> Envoy?: Mercredi 10 Mai 2017 13:55:23 > >> Objet: Environment variables truth source of the JVM (and how to mutate > it) > > > >> Hi, I've been trying to understand how the JVM accesses environment > >> variables and how they can be mutated. > >> > >> I sent an email on this list few minutes ago but it appears to be > >> ill-formatted and hardly legible. Sorry for double post: I resend it > >> with better formatting hopefully. > >> > >> For this I've made some assumptions and I would like to know if they're > >> correct, could you help me on this? > >> > >> 1) It appears that the JVM gets a copy of its process environment > >> variables and store them in static final fields > >> theUnmodifiableEnvironment and theEnvironment of class > >> java.lang.ProcessEnvironment. > >> > >> - My assumption is: these fields are the "truth source" about > >> environment variables inside the JVM and any attempt to access some of > >> them will end up in a lookup of this fields. > >> > >> - I have a question about this: why two final fields instead of only > >> one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst > >> theEnvironment is for env of current process (which could be changed > >> with Process.exec(String[] cmdarray, String[] envp, File dir))? > >> > >> 2) There is a subtle way to mutate them in Sun JDK (see > >> http://www.javaspecialists.eu/archive/Issue161.html). > >> > >> - My assumption is: These fields are passed to all new JVM threads, so > >> mutating them (as ugly as it can sound) will be JVM-wide and will > >> result in all thread getting mutated env as their environment > >> variables. > >> > >> - Sensitive question: is this enforced? System.getenv() appears to > >> correctly returns mutated env, can I deduce all new threads in the JVM > >> will get mutated values? > >> > >> - Another sensitive question: as these fields are static final, can I > >> deduce all threads in the JVM will get mutated values, not only new > >> ones? > >> > >> It would be my pleasure to provide further details ifneedsbe. Just let > >> me know if some of the above assumptions are incorrect! Again, please > >> forgive that double post. > >> > >> Yours faithfully, > >> > >> p2b > From dalibor.topic at oracle.com Wed May 10 16:40:59 2017 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 10 May 2017 18:40:59 +0200 Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: References: <6383-5912ff80-2f-2c82f7c0@208121712> <1273998506.1456873.1494423129704.JavaMail.zimbra@u-pem.fr> Message-ID: <9A8A4450-5C81-4207-AECC-E99F4F4648A8@oracle.com> Yeah, I can imagine ... yikes. To ask the next obvious rhetorical question: would presenting the fiction of mutability of environment variables to user code be a nice feature (even if it doesn't actually work)? I am shell-shocked someone would think that would be a safe thing to do. Cheers, Dalibor Topi? -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment > On 10. May 2017, at 17:40, Martin Buchholz wrote: > > Crashes due to thread-unsafety of putenv/getenv are observed in the wild! > >> On Wed, May 10, 2017 at 7:39 AM, Dalibor Topic wrote: >> Yeah, you should not mutate the environment variables of any multi threaded application once it's running. I don't recall if the result was undefined or unspecified behavior, but it was unreliable behavior in any case. >> >> Cheers, >> Dalibor Topi? >> -- >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | Mobile: +491737185961 >> >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >> >> Oracle is committed to developing >> practices and products that help protect the environment >> >> > On 10. May 2017, at 15:32, Remi Forax wrote: >> > >> > Hi Pierre, >> > it's more a question for the core-dev mailing list. >> > >> > The trick shown by Heinz does not work anymore with jdk 9. >> > >> > You can not mutate the environment variables of jdk, >> > i repeat YOU CAN NOT MUTATE THE ENVIRONMENT VARIABLES OF THE JDK :) >> > >> > But you can send a new environment each time you create a new process, >> > Using ProcessBuilder.environment(). >> > >> > cheers, >> > R?mi >> > >> > ----- Mail original ----- >> >> De: pierre at 2bst.fr >> >> ?: discuss at openjdk.java.net >> >> Envoy?: Mercredi 10 Mai 2017 13:55:23 >> >> Objet: Environment variables truth source of the JVM (and how to mutate it) >> > >> >> Hi, I've been trying to understand how the JVM accesses environment >> >> variables and how they can be mutated. >> >> >> >> I sent an email on this list few minutes ago but it appears to be >> >> ill-formatted and hardly legible. Sorry for double post: I resend it >> >> with better formatting hopefully. >> >> >> >> For this I've made some assumptions and I would like to know if they're >> >> correct, could you help me on this? >> >> >> >> 1) It appears that the JVM gets a copy of its process environment >> >> variables and store them in static final fields >> >> theUnmodifiableEnvironment and theEnvironment of class >> >> java.lang.ProcessEnvironment. >> >> >> >> - My assumption is: these fields are the "truth source" about >> >> environment variables inside the JVM and any attempt to access some of >> >> them will end up in a lookup of this fields. >> >> >> >> - I have a question about this: why two final fields instead of only >> >> one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst >> >> theEnvironment is for env of current process (which could be changed >> >> with Process.exec(String[] cmdarray, String[] envp, File dir))? >> >> >> >> 2) There is a subtle way to mutate them in Sun JDK (see >> >> http://www.javaspecialists.eu/archive/Issue161.html). >> >> >> >> - My assumption is: These fields are passed to all new JVM threads, so >> >> mutating them (as ugly as it can sound) will be JVM-wide and will >> >> result in all thread getting mutated env as their environment >> >> variables. >> >> >> >> - Sensitive question: is this enforced? System.getenv() appears to >> >> correctly returns mutated env, can I deduce all new threads in the JVM >> >> will get mutated values? >> >> >> >> - Another sensitive question: as these fields are static final, can I >> >> deduce all threads in the JVM will get mutated values, not only new >> >> ones? >> >> >> >> It would be my pleasure to provide further details ifneedsbe. Just let >> >> me know if some of the above assumptions are incorrect! Again, please >> >> forgive that double post. >> >> >> >> Yours faithfully, >> >> >> >> p2b > From martinrb at google.com Wed May 10 19:23:07 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 May 2017 12:23:07 -0700 Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: <9A8A4450-5C81-4207-AECC-E99F4F4648A8@oracle.com> References: <6383-5912ff80-2f-2c82f7c0@208121712> <1273998506.1456873.1494423129704.JavaMail.zimbra@u-pem.fr> <9A8A4450-5C81-4207-AECC-E99F4F4648A8@oracle.com> Message-ID: The "big" thing to fix culture wise is a place to document OS-specific behavior. https://bugs.openjdk.java.net/browse/JDK-8173654 Probably we should preserve the current status that environment variables and other global state like cwd can only be modified indirectly by starting a subprocess. On Wed, May 10, 2017 at 9:40 AM, Dalibor Topic wrote: > Yeah, I can imagine ... yikes. > > To ask the next obvious rhetorical question: would presenting the fiction > of mutability of environment variables to user code be a nice feature (even > if it doesn't actually work)? > > I am shell-shocked someone would think that would be a safe thing to do. > > Cheers, > Dalibor Topi? > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214> | Mobile: > +491737185961 > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > On 10. May 2017, at 17:40, Martin Buchholz wrote: > > Crashes due to thread-unsafety of putenv/getenv are observed in the wild! > > On Wed, May 10, 2017 at 7:39 AM, Dalibor Topic > wrote: > >> Yeah, you should not mutate the environment variables of any multi >> threaded application once it's running. I don't recall if the result was >> undefined or unspecified behavior, but it was unreliable behavior in any >> case. >> >> Cheers, >> Dalibor Topi? >> -- >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | Mobile: +491737185961 >> >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >> >> Oracle is committed to developing >> practices and products that help protect the environment >> >> > On 10. May 2017, at 15:32, Remi Forax wrote: >> > >> > Hi Pierre, >> > it's more a question for the core-dev mailing list. >> > >> > The trick shown by Heinz does not work anymore with jdk 9. >> > >> > You can not mutate the environment variables of jdk, >> > i repeat YOU CAN NOT MUTATE THE ENVIRONMENT VARIABLES OF THE JDK :) >> > >> > But you can send a new environment each time you create a new process, >> > Using ProcessBuilder.environment(). >> > >> > cheers, >> > R?mi >> > >> > ----- Mail original ----- >> >> De: pierre at 2bst.fr >> >> ?: discuss at openjdk.java.net >> >> Envoy?: Mercredi 10 Mai 2017 13:55:23 >> >> Objet: Environment variables truth source of the JVM (and how to >> mutate it) >> > >> >> Hi, I've been trying to understand how the JVM accesses environment >> >> variables and how they can be mutated. >> >> >> >> I sent an email on this list few minutes ago but it appears to be >> >> ill-formatted and hardly legible. Sorry for double post: I resend it >> >> with better formatting hopefully. >> >> >> >> For this I've made some assumptions and I would like to know if they're >> >> correct, could you help me on this? >> >> >> >> 1) It appears that the JVM gets a copy of its process environment >> >> variables and store them in static final fields >> >> theUnmodifiableEnvironment and theEnvironment of class >> >> java.lang.ProcessEnvironment. >> >> >> >> - My assumption is: these fields are the "truth source" about >> >> environment variables inside the JVM and any attempt to access some >> of >> >> them will end up in a lookup of this fields. >> >> >> >> - I have a question about this: why two final fields instead of only >> >> one? Perhaps theUnmodifiableEnvironment stands for base JVM env >> whilst >> >> theEnvironment is for env of current process (which could be changed >> >> with Process.exec(String[] cmdarray, String[] envp, File dir))? >> >> >> >> 2) There is a subtle way to mutate them in Sun JDK (see >> >> http://www.javaspecialists.eu/archive/Issue161.html). >> >> >> >> - My assumption is: These fields are passed to all new JVM threads, so >> >> mutating them (as ugly as it can sound) will be JVM-wide and will >> >> result in all thread getting mutated env as their environment >> >> variables. >> >> >> >> - Sensitive question: is this enforced? System.getenv() appears to >> >> correctly returns mutated env, can I deduce all new threads in the >> JVM >> >> will get mutated values? >> >> >> >> - Another sensitive question: as these fields are static final, can I >> >> deduce all threads in the JVM will get mutated values, not only new >> >> ones? >> >> >> >> It would be my pleasure to provide further details ifneedsbe. Just let >> >> me know if some of the above assumptions are incorrect! Again, please >> >> forgive that double post. >> >> >> >> Yours faithfully, >> >> >> >> p2b >> > > From david.holmes at oracle.com Thu May 11 00:45:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 May 2017 10:45:59 +1000 Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: References: <6383-5912ff80-2f-2c82f7c0@208121712> <1273998506.1456873.1494423129704.JavaMail.zimbra@u-pem.fr> <9A8A4450-5C81-4207-AECC-E99F4F4648A8@oracle.com> Message-ID: Can we please stop discussing this on the discuss list! :) Thanks you. David On 11/05/2017 5:23 AM, Martin Buchholz wrote: > The "big" thing to fix culture wise is a place to document OS-specific > behavior. > > https://bugs.openjdk.java.net/browse/JDK-8173654 > > Probably we should preserve the current status that environment variables > and other global state like cwd can only be modified indirectly by starting > a subprocess. > > On Wed, May 10, 2017 at 9:40 AM, Dalibor Topic > wrote: > >> Yeah, I can imagine ... yikes. >> >> To ask the next obvious rhetorical question: would presenting the fiction >> of mutability of environment variables to user code be a nice feature (even >> if it doesn't actually work)? >> >> I am shell-shocked someone would think that would be a safe thing to do. >> >> Cheers, >> Dalibor Topi? >> -- >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214> | Mobile: >> +491737185961 >> > >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >> >> Oracle is committed to developing >> practices and products that help protect the environment >> >> On 10. May 2017, at 17:40, Martin Buchholz wrote: >> >> Crashes due to thread-unsafety of putenv/getenv are observed in the wild! >> >> On Wed, May 10, 2017 at 7:39 AM, Dalibor Topic >> wrote: >> >>> Yeah, you should not mutate the environment variables of any multi >>> threaded application once it's running. I don't recall if the result was >>> undefined or unspecified behavior, but it was unreliable behavior in any >>> case. >>> >>> Cheers, >>> Dalibor Topi? >>> -- >>> Dalibor Topic | Principal Product Manager >>> Phone: +494089091214 | Mobile: +491737185961 >>> >>> >>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >>> >>> ORACLE Deutschland B.V. & Co. KG >>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >>> Registergericht: Amtsgericht M?nchen, HRA 95603 >>> >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >>> >>> Oracle is committed to developing >>> practices and products that help protect the environment >>> >>>> On 10. May 2017, at 15:32, Remi Forax wrote: >>>> >>>> Hi Pierre, >>>> it's more a question for the core-dev mailing list. >>>> >>>> The trick shown by Heinz does not work anymore with jdk 9. >>>> >>>> You can not mutate the environment variables of jdk, >>>> i repeat YOU CAN NOT MUTATE THE ENVIRONMENT VARIABLES OF THE JDK :) >>>> >>>> But you can send a new environment each time you create a new process, >>>> Using ProcessBuilder.environment(). >>>> >>>> cheers, >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: pierre at 2bst.fr >>>>> ?: discuss at openjdk.java.net >>>>> Envoy?: Mercredi 10 Mai 2017 13:55:23 >>>>> Objet: Environment variables truth source of the JVM (and how to >>> mutate it) >>>> >>>>> Hi, I've been trying to understand how the JVM accesses environment >>>>> variables and how they can be mutated. >>>>> >>>>> I sent an email on this list few minutes ago but it appears to be >>>>> ill-formatted and hardly legible. Sorry for double post: I resend it >>>>> with better formatting hopefully. >>>>> >>>>> For this I've made some assumptions and I would like to know if they're >>>>> correct, could you help me on this? >>>>> >>>>> 1) It appears that the JVM gets a copy of its process environment >>>>> variables and store them in static final fields >>>>> theUnmodifiableEnvironment and theEnvironment of class >>>>> java.lang.ProcessEnvironment. >>>>> >>>>> - My assumption is: these fields are the "truth source" about >>>>> environment variables inside the JVM and any attempt to access some >>> of >>>>> them will end up in a lookup of this fields. >>>>> >>>>> - I have a question about this: why two final fields instead of only >>>>> one? Perhaps theUnmodifiableEnvironment stands for base JVM env >>> whilst >>>>> theEnvironment is for env of current process (which could be changed >>>>> with Process.exec(String[] cmdarray, String[] envp, File dir))? >>>>> >>>>> 2) There is a subtle way to mutate them in Sun JDK (see >>>>> http://www.javaspecialists.eu/archive/Issue161.html). >>>>> >>>>> - My assumption is: These fields are passed to all new JVM threads, so >>>>> mutating them (as ugly as it can sound) will be JVM-wide and will >>>>> result in all thread getting mutated env as their environment >>>>> variables. >>>>> >>>>> - Sensitive question: is this enforced? System.getenv() appears to >>>>> correctly returns mutated env, can I deduce all new threads in the >>> JVM >>>>> will get mutated values? >>>>> >>>>> - Another sensitive question: as these fields are static final, can I >>>>> deduce all threads in the JVM will get mutated values, not only new >>>>> ones? >>>>> >>>>> It would be my pleasure to provide further details ifneedsbe. Just let >>>>> me know if some of the above assumptions are incorrect! Again, please >>>>> forgive that double post. >>>>> >>>>> Yours faithfully, >>>>> >>>>> p2b >>> >> >>