Intermittent ConcurrentModificationException constructing scala.tools.nsc.Settings

[scabug]

Seeing this very intermittently when constructing scala.tools.nsc.Settings

Ever-so-slightly similar to #7269

java.util.ConcurrentModificationException
	at java.util.Hashtable$Enumerator.next(Hashtable.java:1200)
	at scala.collection.convert.Wrappers$JPropertiesWrapper$$anon$3.next(Wrappers.scala:458)
	at scala.collection.convert.Wrappers$JPropertiesWrapper$$anon$3.next(Wrappers.scala:454)
	at scala.collection.Iterator$class.find(Iterator.scala:779)
	at scala.collection.AbstractIterator.find(Iterator.scala:1157)
	at scala.tools.util.PathResolver$Environment$.searchForBootClasspath(PathResolver.scala:43)
	at scala.tools.util.PathResolver$Environment$.javaBootClassPath(PathResolver.scala:52)
	at scala.tools.util.PathResolver$Defaults$.javaBootClassPath(PathResolver.scala:82)
	at scala.tools.nsc.settings.StandardScalaSettings$class.$init$(StandardScalaSettings.scala:25)
	at scala.tools.nsc.settings.MutableSettings.<init>(MutableSettings.scala:19)
	at scala.tools.nsc.Settings.<init>(Settings.scala:12)
	at scala.tools.nsc.doc.Settings.<init>(Settings.scala:15)

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7775?orig=1
Reporter: James Koch (jameskoch2)
Affected Versions: 2.10.1
See #7269

[scabug]

@retronym said:
The default command line compiler is single threaded. What environment / build tool are you using?

[scabug]

@retronym said:
Oh, I see from #7269 that this can happen with a single thread!

[scabug]

James Koch (jameskoch2) said:
That said, I am in a somewhat custom environment here, kicking off doc compilation while doing unrelated work on other threads. It's possible that one of those called System.setProperty and caused this.

[scabug]

@retronym said:
We'll need a test case that tries to reproduce this. Perhaps it is just the linked ticket, I'll take a look at that one.

[scabug]

James Koch (jameskoch2) said:

def SI7269() {
  import scala.concurrent.{duration, future, Await, ExecutionContext}
  import scala.tools.nsc.Settings
  import ExecutionContext.Implicits.global

  val tries = 5000 // YMMV
  val compiler = future {
    for(_ <- 1 to tries) new Settings(_ => {})
  }
  for(i <- 1 to tries * 10) System.setProperty(s"foo$i", i.toString)
  Await.result(compiler, duration.Duration.Inf)
}

In my particular case, it's really convenient to be able to spin up a compiler inside a process that's concurrently performing non-compiler work. Given all of the possible usages of setProperty, this defect limits that capability. Just looking around the JDK itself, something as simple as initializing a new java.util.Date might set a property ("user.timezone").

[scabug]

@som-snytt said:
It looks like Properties.stringPropertyNames is the API for getting a snapshot that is not backed by the properties object. PathResolver.Environment can use that when probing for a *.boot.class.path.

[scabug]

@retronym said:
scala/scala#2868

[scabug]

@lrytz said:
Improvement in scala/scala#4372