|ejc failing to build with StackOverflowError [message #1765036]
||Mon, 05 June 2017 22:18
| Richard Steiger
Registered: May 2017
host: Dell XPS 8920, Windows 10 pro|
IDE version: eclipse-java-oxygen-M7-win32-x86_64
JDK version: jdk1.8.0_152
jdt version: org.eclipse.jdt.core_3.13.0.v20170516-1929
I originally described this bug through comments to "Bug 432541 Stack Overflow in Java Search - type inference issue?". After this bug had been verified fixed, I began seeing the identical symptoms, and added comment 44 to this effect on 2017-3-1. Stephan Herrmann suggested not simply reopening 432541, but to document the issue separately, so a decision to reopen could be made on its own merits.
When viewed in the Error Log, the backtrace leaves no evidence (initial calls are clobbered by the copious StackOverflowError.<init> calls), but occasionally the error notifier popup in the editor contains the following call:
I've been able to narrow the occurrence of this bug to a single java project (having either a Java or Maven nature), where it fails 100% reproducibly, thereby blocking the project's development.
The project contains ~1500 source files, and makes very heavy use of generics, and in numerous places, complex, mutually-recursive type signatures. It seems to be happening in a set of types representing digraphs, where some signatures (e.g. Node) have 2 parameters for edges (source and target), and can't be further simplified. Unfortunately, this set of types is woven with many other types, and all attempts to isolate a small repro set have failed. I know of no workaround.
I've seen this failure occur with both java 7 and 8, and in neon-1, neon-2, and oxygen-m5, m6, and m7.
My current root-cause theory is that the type inferencer is failing to distinguish multiple synonymous type parameters by their positions in member or type declarations, thereby getting confused when traversing some type decl's type graph, basically missing the fact that it's already processed a binding in a previous position, and repetitively reprocesssing the binding.
Given this current blocker, I've had to migrate several projects to IDEA, which has an inferior project and module model, greatly hampering productivity.
I'm therefore motivated to roll-up my sleeves and attempt fixing this bug. Being a total eclipse development noobie, having someone experienced in eclipse development, ideally familiar with ejc internals, to advise me when I get stuck would raise the likelihood of me fixing the bug. If there are any documents covering ejc's type inferencer's design, those would be most helpful to orienting myself to the code.
At Ed Merks' suggestion, I've installed the JDT dev env via Oomph. I imagine that reasonable next steps will be to fire-up eclipse under JDT, set a breakpoint in the ParameterizedTypeBinding.collectInferenceVariables() method, and trigger ejc to do a rebuild, then follow the yellow brick road from there. Any better suggestions?
Any and all guidance is welcome.
Powered by FUDForum
. Page generated in 0.01392 seconds