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
