Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] possible bugs and unexpected values in returned errors classes
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-02-12 19:02:44


On Feb 11, 2009, at 8:24 AM, Lisandro Dalcin wrote:

> Below a list of stuff that I've got by running mpi4py testsuite. Never
> reported them before just because some of them are not actually
> errors, but anyway, I want to raise the discussion.
>
> - Likely bugs (regarding my interpretation of the MPI standard)
>
> 1) When passing MPI_REQUEST_NULL, MPI_Request_free() DO NOT fail.
>
> 2) When passing MPI_REQUEST_NULL, MPI_Cancel() DO NOT fail.
>
> 3) When passing MPI_REQUEST_NULL, MPI_Request_get_status() DO NOT
> fail.

I agree with all of these; I'm not sure why we allowed
MPI_REQUEST_NULL. I double checked LAM/MPI -- it errors in all of
these cases. So OMPI now does, too.

> 4) When passing MPI_WIN_NULL, MPI_Win_get_errhandler() and
> MPI_Win_set_errhandler() DO NOT fail.

I was a little more dubious here; the param checking code was
specifically checking for MPI_WIN_NULL and not classifying it as an
error. Digging to find out why we did that, the best that I can come
up with is that it is *not* an error to call MPI_File_set|
get_errhandler on MPI_FILE_NULL (to set behavior for what happens when
FILE_OPEN fails); I'm *guessing* that we simply copied the _File_ code
to the _Win_ code and forgot to remove that extra check.

I can't find anything in MPI-2.1 that says it is legal to call set|get
errhandler on MPI_WIN_NULL. I checked LAM as well; LAM errors in this
case. So I made this now be an error in OMPI as well.

Do you need these in the 1.3 series? Or are you ok waiting for 1.4
(assuming 1.4 takes significantly less time to release than 1.3 :-) ).

> - Unexpected errors classes (at least for me)
>
> 1) When passing MPI_COMM_NULL, MPI_Comm_get_errhandler() fails with
> MPI_ERR_ARG. I would expect MPI_ERR_COMM.

I don't have a strong feeling on this one; I think you could probably
argue either way. That being said, we haven't paid too close
attention to the error values that we return. Unfortunately, I don't
think there's much standardization between different MPI
implementations, unless they share a common code ancestry.

> 2) MPI_Type_free() fails with MPI_ERR_INTERN when passing predefined
> datatypes like MPI_INT or MPI_FLOAT. I would expect MPI_ERR_TYPE.

Ya, that seems weird. Fixed.

> - Controversial (I'm even fine with the current behavior)
>
> 1) MPI_Info_get_nthkey(info, n) returns MPI_ERR_INFO_KEY when "n" is
> larger that the number of keys. Perhaps MPI_ERR_ARG would be more
> appropriate? A possible rationale would be that the error is not
> related to the contents of a 'key' string, but an out of range value
> for "n".

I don't have a particular opinion on this one.

> That's all. Sorry for being so pedantic :-) and not offering help for
> the patches, but I'm really busy.

No worries; this stuff is great. Thanks -- and keep it coming! (we
usually remember to cite people who submit stuff like this; e.g., https://svn.open-mpi.org/trac/ompi/changeset/20537
  and https://svn.open-mpi.org/trac/ompi/changeset/20538).

-- 
Jeff Squyres
Cisco Systems