FWIW: this isn't a bug in orte_dpm, but in the MPI binding for comm_join. The problem is that both sides in the comm_join are setting "send_first" to true - i.e., both sides are trying to be the first to send on the handshake. We got away with this before because of a bug in orte_dpm that made the value of send_first irrelevant, but that has now been fixed.
So someone needs to figure out how to properly set "send_first" in comm_join so that the two sides agree on who does what first. Looking at the code, it isn't obvious to me how one would do so as I don't see any rank info passed into the function.
On Apr 9, 2012, at 8:31 AM, Josh Hursey wrote:
> This is totally not related to the bug report, but a neat trick in Trac.
> My question was "what were the commits between r26240 and 26249"?
> In the search box type:
> Or use the direct url:
> -- Josh
> On Mon, Apr 9, 2012 at 9:17 AM, TERRY DONTJE <terry.dontje_at_[hidden]> wrote:
>> After looking at Oracles MTT results there seem to be a (some??) regressions
>> between r26240 and 26249 detected by the ibm and intel tests suites. An
>> example of this is the failures in the comm_join, final and loop_spawn tests
>> of the ibm test suite as seen in
>> Note, I've seen similar errors detected by IU runs too.
>> I'll look further into this but I thought I would post this just in case
>> someone else has seen this.
>> Terry D. Dontje | Principal Software Engineer
>> Developer Tools Engineering | +1.781.442.2631
>> Oracle - Performance Technologies
>> 95 Network Drive, Burlington, MA 01803
>> Email terry.dontje_at_[hidden]
>> devel mailing list
> Joshua Hursey
> Postdoctoral Research Associate
> Oak Ridge National Laboratory
> devel mailing list