You're remembering correctly regarding the hack. It was added not because we were removing the ref types, but rather never adding them. The hack was removed in r22824 because we had since taken care of creating the ref types for primitives in the compiler. Regardless, I don't think the original hack would have helped in this case based on Alexey's analysis that the ref type is being removed (which makes perfect sense).
I'm not sure if there's a xtruly satisfying way to fix this, but there are at least two that are decent. One way is to *not* prune the ref types of primitive types. The other is to check for the existence of the ref type when adding moduleInitLevel, and create it if it doesn't exist. -- Sung On Fri, Jun 27, 2014 at 02:04:57PM -0700, Brad Chamberlain wrote: > > Hi Chapel Developers -- > > I know a few people have run into the following issue, or one like it, in > recent years (the issue being "necessary ref temps have gone missing"). I > know Michael did externally, put in a hack to fix it, at some point we > thought the world was better and (I believe) removed the hack. I think > David might have some knowledge here as well, perhaps? > > Can someone who is closer to this topic than I am comment on what Alexey's > running into and whether or not it is surprising? > > Thanks, > -Brad > > > ---------- Forwarded message ---------- > Date: Fri, 27 Jun 2014 13:33:03 -0500 > From: Alexey Gokhberg <[email protected]> > To: Brad Chamberlain <[email protected]> > Subject: Potential bug > > Hello Brad > > As part of my research I have created a restricted version of Chapel module > library for v.1.9. This version targets a serial subset of Chapel, that is, > it does not support sync/single/atomic types; does not understand any of > parallel or locale-aware statements; does not at all understand locales (I > included a dummy ChapelLocale module just for aliby because compiler requires > a few types from it); it also supports no particular distributions from > "dists" section. (I have also created a matching restricted code generator; > my principal goal is investigation of Chapel serial performance and > opportunities to improve it.) > > During this development I have encountered a funny issue: function > "addPrintModInitOrder" in "passes/addInitGuards.c" signaled a failed > assertion because field "refType" of type of "moduleInitLevel" variable in > "PrintModuleInitOrder" package was NULL at this point. But this type is > simply "int(32)", so how could this happen? And why does this happen with my > reduced version but not with the original complete set of Chapel modules? > > Detailed inquiry had shown that most of "refType" fields are lazily created > during type resoilution using "makeRefType" function in > "functionResolution.cpp". Reference type for "int(32)" is created exactly > this way. Furthermore, pass "prune" will delete unused reference types "using > pruneUnusedRefs" function in "ast/astutil.c". It appears that un case of my > reduced module set the reference type for "int(32)" is killed exactly this > way. When time for "addPrintModInitOrder" comes, the function attempts to > construct the respective function call assuming that the reference type is > still available, which is not a case. > > This does not happen with the full module set because apparently references > to "int(32)" variables are actually used by the live code. The entire issue > thus appears to be not that important for the main Chapel branch; > nevertheless it should be classified as a bug that may have impact on > possible variations in the module library. > > (Please note that I have traced precisely the described compiler behavior for > both module sets.) > > For the time being I have just disabled "addPrintModInitOrder" functionality > in my compiler version (I do not need it anyway; "PrintModuleInitOrder" > module was included only because compiler insisted on that); then I was able > to continue my work. Perhaps you would like to bring the issue to the > attention of your team to close this potential vulnerability (one simple > workaround woud be to suppress pruning of references for Chapel base types). > > Best regards > > Alexey > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
