Scala Programming Language
  1. Scala Programming Language
  2. SI-7775

Intermittent ConcurrentModificationException constructing scala.tools.nsc.Settings

    Details

      Description

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

      Ever-so-slightly similar to SI-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)
      

        Issue Links

          Activity

          Hide
          Jason Zaugg added a comment -

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

          Show
          Jason Zaugg added a comment - The default command line compiler is single threaded. What environment / build tool are you using?
          Hide
          Jason Zaugg added a comment -

          Oh, I see from SI-7269 that this can happen with a single thread!

          Show
          Jason Zaugg added a comment - Oh, I see from SI-7269 that this can happen with a single thread!
          Hide
          James Koch added a comment -

          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.

          Show
          James Koch added a comment - 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.
          Hide
          Jason Zaugg added a comment -

          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.

          Show
          Jason Zaugg added a comment - 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.
          Hide
          James Koch added a comment -
          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").

          Show
          James Koch added a comment - 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").
          Hide
          A. P. Marki added a comment -

          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`.

          Show
          A. P. Marki added a comment - 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`.
          Show
          Jason Zaugg added a comment - https://github.com/scala/scala/pull/2868

            People

            • Assignee:
              Jason Zaugg
              Reporter:
              James Koch
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development