Hello Don! Am Donnerstag, 7. Januar 2010 23:22:27 schrieben Sie: > I am assuming you are using something other than IPv4 so I am curious > what the string looks like when you call > " > inet_ntop(AF_INET, (void *) &btl_addr->sin_addr, > btl_addr_string, INET_ADDRSTRLEN); > " > > when the address is not of the AF_INET family? Do you have an example > of this? The address is indeed of family AF_INET, e.g. "10.0.0.1".
The issue in btl_udapl_proc is that it does not initialise btl_addr_string for every possible code path (peer_proc->proc_addr_count <= 0). Thus the error message sent by the nodes may contain garbage / uninitialised bytes. (As in our case.) I fixed that by initialising btl_addr_string at the earliest possible point, which is outside the AF_INET check and the loop over the proc addresses. This also prevents the string from being copied multiple times within the loop, which seems just unnecessary. You are right with your doubts that the move out of the check for AF_INET is correct, since inet_ntop is called for af=AF_INET. It should better be located inside the if block. The reason that peer_proc->proc_addr_count was <= 0 must have had something to do with uDAPL not being setup correctly on our cluster. (I didnt check for the exact value of peer_proc->proc_addr_count, just guessed, because the loop was obviously never executed.) We actually want to connect the nodes via IB and uDAPL was just the default BTL choosen by OpenMPI. We are now using "--mca btl openib,self", as we figured out uDAPL is not at all needed to connect the nodes via IB. I still found it reasonable to report the issue detected, together with a possible fix. --Dennis
signature.asc
Description: This is a digitally signed message part.
