Hello Silicon team :)
We found a bug which leads to crashes when Silicon is executed in parallel by a frontend.
Description:
When a frontend runs multiple instances of Silicon's SiliconFrontendAPI in parallel, the execution may fail with a ClassCastException. The root cause should be a init race produced by the used SLF4 setup for logging.
Suspected cause:
During setup, Silicon calls LoggerFactory.getILoggerFactory.asInstanceOf[LoggerContext] in ViperLogger.scala. The first call triggers SLF4J's configuration phase, during which the thread blocks. However, when multiple instances are run in parallel, other calls can be made during the setup phase, for which the factory returns substitute loggers. These lead to the ClassCastException:
java.lang.ClassCastException: class org.slf4j.helpers.SubstituteLoggerFactory
cannot be cast to class ch.qos.logback.classic.LoggerContext
at viper.silver.logger.ViperStdOutLogger...
at viper.silicon.SiliconFrontendAPI.<init>(...)
Reproduction:
Running parallel JUnit tests on a frontend using Silicon should recreate the bug. You can also have a look at our corresponding PR.
Proposed fix:
We fixed it in the frontend by blocking until the configuration phase has finished. It could also be fixed by enabling frontends to set the loggers, blocking yourself or supporting the substitute loggers.
Hello Silicon team :)
We found a bug which leads to crashes when Silicon is executed in parallel by a frontend.
Description:
When a frontend runs multiple instances of Silicon's
SiliconFrontendAPIin parallel, the execution may fail with aClassCastException. The root cause should be a init race produced by the used SLF4 setup for logging.Suspected cause:
During setup, Silicon calls
LoggerFactory.getILoggerFactory.asInstanceOf[LoggerContext]inViperLogger.scala. The first call triggers SLF4J's configuration phase, during which the thread blocks. However, when multiple instances are run in parallel, other calls can be made during the setup phase, for which the factory returns substitute loggers. These lead to the ClassCastException:Reproduction:
Running parallel JUnit tests on a frontend using Silicon should recreate the bug. You can also have a look at our corresponding PR.
Proposed fix:
We fixed it in the frontend by blocking until the configuration phase has finished. It could also be fixed by enabling frontends to set the loggers, blocking yourself or supporting the substitute loggers.