<div dir="ltr">Thanks, Martin, for sharing some advanced ideas. <div><br></div><div>I spent a few minutes trying to find out more, throwing a diagnostic compile line at the problem :<div><p style="margin:0px;font-size:11px;font-family:Menlo">
-gen-interfaces -warn interfaces -fp-stack-check -g -traceback -check arg_temp_created -check bounds </p></div><div>trying to catch anything potentially suspicious. The problem with most codes I've worked on is that you typically catch a bunch of unrelated things that obscure the analysis :). In this case, e.g., the argument F to TrustStep (called before the NormS mentioned earlier) is an allocated array on one side and implicit on the other, and that offends the compile options above. I don't have much time for analysis right now - maybe the mixer developers will immediately spot what's going on in my earlier e-mail. "check bounds" or "check all" by themselves don't give any runtime diagnostics, so I'm guessing we're not overstepping array bounds explicitly.</div>
<div><br></div><div>If you have a more specific idea for a test, I or maybe Jianxin can try to run it for you. I guess a basic one would be to just do the run_lapw calculation on Linux vs. Mac (with -heap-arrays) and see if the results are identical.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>Kevin</div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 31, 2014 at 4:29 PM, Martin Kroeker <span dir="ltr"><<a href="mailto:martin@ruby.chemie.uni-freiburg.de" target="_blank">martin@ruby.chemie.uni-freiburg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This might warrant closer scrutiny - was it reproducible with any odd<br>
tutorial problem, or does it require a particular case or type of<br>
calculation ?<br>
The "illegal instruction" abort signals that data was somehow spilling<br>
over into the memory ranges holding the executable code. Now I would not<br>
expect a "simple" heap-stack-collision (from an array that is simply too<br>
big to put on the stack with impunity) to occur on any modern system<br>
except perhaps severely constrained embedded ones. At worst, the abort<br>
should have been accompanied by a "segmentation fault" message as the<br>
attempt to overwrite the running program got caught. So other possible<br>
explanations could be that the code tries to store more array elements<br>
than the array was designed to hold, or that the indexes into the array<br>
are miscalculated (overflowing or not clamped to positive values).<br>
Moving data to the heap may have just changed the location of the<br>
inadvertently overwritten memory to ranges where the effects are more<br>
subtle (unrelated data) or not noticable (lucky hit on unused memory).<br>
<span class="HOEnZb"><font color="#888888">--<br>
Dr. Martin Kroeker <a href="mailto:martin@ruby.chemie.uni-freiburg.de">martin@ruby.chemie.uni-freiburg.de</a><br>
c/o Prof.Dr. Caroline Roehr<br>
Institut fuer Anorganische und Analytische Chemie der Universitaet Freiburg<br>
<br>
_______________________________________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at">Wien@zeus.theochem.tuwien.ac.at</a><br>
<a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
SEARCH the MAILING-LIST at: <a href="http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html" target="_blank">http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html</a><br>
</font></span></blockquote></div><br></div>