Environment variables truth source of the JVM (and how to mutate it)
martinrb at google.com
Wed May 10 15:40:20 UTC 2017
Crashes due to thread-unsafety of putenv/getenv are observed in the wild!
On Wed, May 10, 2017 at 7:39 AM, Dalibor Topic <dalibor.topic at oracle.com>
> 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
> Dalibor Topić
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214<tel:+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
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
> > On 10. May 2017, at 15:32, Remi Forax <forax at univ-mlv.fr> 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
> >> 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
More information about the discuss