Problem solved. I discovered that isExternal() could be called before initExterns() returned. The externs member variable would be non-null, but not all of the values had been added yet. I changed initExterns() so that it would add the values a local variable instead, and I waited to set the externs member variable until the end, when all values were guaranteed to be added.
- Josh On Thu, Oct 22, 2015 at 2:39 PM, Josh Tynjala <joshtynj...@gmail.com> wrote: > I tried overriding setTargetSettings(), and that kept the LinkageChecker > from being created more than once. However, that did not fix the issue. The > isExternal() method on the LinkageChecker is still sometimes incorrectly > returning false. I guess that was just a coincidence. > > I'll keep investigating because this is happening pretty frequently for > me. I used to have builds sometimes mysteriously fail on me before, and I > now think it was from this same issue, but it was less frequent then. > > - Josh > > On Wed, Oct 21, 2015 at 6:03 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 10/21/15, 5:35 PM, "Alex Harui" <aha...@adobe.com> wrote: >> >> > >> > >> >On 10/21/15, 4:20 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: >> > >> >>Is the compiler using more than one thread? Could different threads be >> >>calling isExternalLinkage(), and am I seeing a race condition? >> > >> >The compiler uses one thread for each .as file so yes, you are probably >> >seeing a multi-thread issue, although I haven’t checked the call stack >> >into that call to see if it is coming from threads. >> >> So I took a quick look and yes, that code gets called from within the >> threads. I don’t immediately see any reason you would get a different >> answer even if there was a race condition. But you might try overriding >> setTargetSettings and creating the linkageChecker as soon as the >> targetSettings are available and see if that helps. >> >> -Alex >> >> >
