On Fri, Mar 1, 2013 at 12:04 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">----- Original Message -----<br>
> From: "Jack Poulson" <<a href="mailto:jack.poulson@gmail.com">jack.poulson@gmail.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: "Jeff Hammond" <<a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a>>, <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
</div><div class="im">> Sent: Friday, March 1, 2013 10:16:24 AM<br>
> Subject: Re: [Llvm-bgq-discuss] Details behind MPI wrapper for bgclang++<br>
><br>
</div><div><div class="h5">> On Thu, Feb 28, 2013 at 10:15 PM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
><br>
> Not a problem! Thanks for being a beta tester :) I've updated the<br>
> installed libc++ libraries to use CLOCK_REALTIME instead of<br>
> CLOCK_MONOTONIC. Please try again.<br>
><br>
> -Hal<br>
><br>
><br>
><br>
><br>
> One more problem taken care of it seems. Unfortunately my program now<br>
> segfaults in an MPI_Gather call (and the trace still seems a bit<br>
> corrupted, see core.13). There is really only one instance in my<br>
> program where MPI_Gather is called, and it looks like this:<br>
><br>
><br>
> vector<int> myCoords(d), coords(1);<br>
> // <fill myCoords here><br>
> if( commRank == 0 )<br>
> coords.resize( d*commSize );<br>
> MPI_Gather( &myCoords[0], d, MPI_INT, &coords[0], d, MPI_INT, 0, comm<br>
> );<br>
><br>
><br>
> In the above snippet, 'd' is the dimension of the domain, which is<br>
> two for the executable in question, and space for storing every<br>
> process's coordinates is only allocated on the root process. This is<br>
> pretty straightforward MPI in my opinion, so I am skeptical that I<br>
> have a bug here.<br>
<br>
</div></div>Unfortunately, the debug into seems completely useless here. Some of our IBM contributors have been working on fixing problems with debug info, so hopefully this will improve soon.<br>
<br>
In any case, the actual crash is in:<br>
dbf::bfly::PotentialField<float, 2ul, 8ul>::Evaluate(std::__1::array<float, 2ul> const&) const<br>
<br>
just after a call to:<br>
dbf::bfly::Context<float, 2ul, 8ul>::Lagrange(unsigned long, std::__1::array<float, 2ul> const&) const<br>
<br>
Does that give enough context to guess at the source location? Also, can you try linking the executable statically? I wonder if this is some kind of PIC problem.<br>
<br></blockquote><div><br>That is infinitely more information than I had before. What did you do to find this out?<br><br>The latter routine heavily used restrict, but after removing all usages of restrict from my entire program and recompiling I received an essentially identical coredump file (though I suppose that it is possible that the crash occurred somewhere else).<br>
<br>Jack </div></div><br>