
Java's TypeVariable.getBounds is not thread safe - based2
http://vmlens.com/articles/java-lang-reflect-typevariable-getbounds-is-not-thread-safe/
======
barrkel
If this is a bug, it's a bug in the array cloning logic. It's easy to publish
a reference to an incomplete data structure without a memory barrier before
the assignment that publishes it - though x86/x64 platforms will save you by
retiring writes in order [1]. You don't need to use the JDK to replicate this
logic; you could write this code yourself. If it crashes the JVM, it's
probably a violation of memory safety - it's not inconceivable that there's an
exploit here, but at the very least it's a DoS vector for untrusted bytecode.

[1] See [https://bartoszmilewski.com/2008/11/05/who-ordered-memory-
fe...](https://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-
an-x86/) for a readable discussion about what x86/x64 does and doesn't do.

------
ecopoesis
Why did you expect it was threadsafe? I can find nothing in its javadoc that
would lead me to believe it was. Most of the Java standard library isn't
threadsafe, that why there are concurrent objects in addition to their non-
threadsafe cousins and language level synchronization statements.
[https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/...](https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/TypeVariable.html#getBounds--)

~~~
exabrial
It seems there's sort of an unwritten standard that static methods should be
thread safe or avoid shared state :/

Another great failure is UUID.generateRandomUUID(); One would think that's
thread safe... [maybe it's fixed now]

~~~
mikeash
They basically have to be thread safe, because they're globally accessible. If
you can't control access to a call that isn't thread safe, then you can't call
it safely at all if there's any code in your process that you don't control
(like, say, third-party libraries, or even first-party libraries).

I think it's reasonable to assume that any documented API must at least be
callable.

~~~
lomnakkus
Indeed it must be so -- at least it would be _very_ strange to have a thread-
unsafe static method where the documentation doesn't spell out how to use it
safely[1]. Even in that case it would be a weird thing to even have a thread-
unsafe static method (except accidentally, of course).

[1] The JDK documentation is pretty good on spelling out such caveats, IME.

------
Groxx
Hm. Are other things in the reflect package threadsafe? By default I wouldn't
expect it to be since it doesn't seem to claim it is, but it is a little
surprising that a language-introspection feature could just crash because
you're doing it at the same time as someone else. And it seems hard to guard
against - you could carefully lock on the class for your own code, but you
can't really guarantee libraries will work with that (e.g. they may get into
deadlocks).

------
benmmurphy
this crash is kind of interesting because i don't see any 'unsafe' code* in
this getBounds() implementation so it shouldn't crash the JDK. like the code
is broken in how it works but it shouldn't be possible to muck around with
threading a race and then call clone and crash the JDK.

* the code is very abstract and touches a lot of classes so there could be some unsafe code hiding there i can't see.

~~~
brabel
It seems to me that the main cause of the crash is the fact that the author
used a special [classloader]([https://github.com/vmlens/jcstress-
examples/blob/master/src/...](https://github.com/vmlens/jcstress-
examples/blob/master/src/main/java/com/vmlens/stressTest/util/StressTestClassLoader.java))
which always reloads the class and is not thread-safe intentionally
(classloaders should be Thread-safe). I did not investigate in depth but that
seems to be the main problem to me.

------
p1mrx
My favorite non-thread-safe part of Java is this:

    
    
        SimpleDateFormat YMD = new SimpleDateFormat("yyyy-MM-dd");
    

If you call YMD.parse() from multiple threads, it will sometimes return the
wrong date. Cleaning up the database after that bug was loads of fun.

~~~
sz4kerto
This is documented properly though.

------
killin_dan
The assumption "threadsafe until proven otberwise" has bitten so many people,
you'd think they would eventually learn.

Oh wait, they're Java programmers. ;p

