diff options
author | Eugene Burmako <xeno.by@gmail.com> | 2014-03-07 20:44:27 +0100 |
---|---|---|
committer | Eugene Burmako <xeno.by@gmail.com> | 2014-03-07 20:44:27 +0100 |
commit | aa93dafcbec6cb3436e0222d633611769ebf74bf (patch) | |
tree | 4e24f0439b5f6931d86b36e542bafb19ec04506d /push-binary-libs.sh | |
parent | 2dddb03b267770afcd0249ad700e55d53019e637 (diff) | |
download | scala-aa93dafcbec6cb3436e0222d633611769ebf74bf.tar.gz scala-aa93dafcbec6cb3436e0222d633611769ebf74bf.tar.bz2 scala-aa93dafcbec6cb3436e0222d633611769ebf74bf.zip |
SI-8370 fixes an infinite loop in repl init
Under a weird coincidence of circumstances provided by `sbt console-quick`,
new XML parsing logic in compiler plugin initialization could lead to stack
overflow errors.
Here's the abridged sequence events that led to this unfortunate problem
(full description can be found on the JIRA issue page):
1) Initialization of the compiler underlying the REPL would kick off
plugin initialization.
2) PluginDescription.fromXML would call into DocumentBuilderFactory, i.e.
DocumentBuilderFactory.newInstance.newDocumentBuilder.parse(xml).
3) That thing would call into javax.xml.parsers.SecuritySupport.getResourceAsStream,
requesting META-INF/services/javax.xml.parsers.DocumentBuilderFactory.
4) That request would get serviced by TranslatingClassLoader provided
by the REPL to expose dynamically compiled code.
5) TranslatingClassLoader would call translatePath that would call into
IMain.symbolOfIdent trying to map the requested resource onto one of the
classes defined by the REPL (which don't exist yet, because REPL hasn't
yet finished initializing).
6) IMain.symbolOfIdent would request IMain.global, which is exactly the
instance of the compiler that underlies the REPL, and that's currently
being initialized.
7..inf) Repeat until a StackOverflowError.
Diffstat (limited to 'push-binary-libs.sh')
0 files changed, 0 insertions, 0 deletions