I compromised: see https://svn.open-mpi.org/trac/ompi/changeset/25432.
If someone has strong feelings, go ahead and change it. This is a rare enough issue that I don't think we need to spend much more time on it. On Nov 2, 2011, at 2:22 PM, Barrett, Brian W wrote: > To be honest, I don't care so much today, I'm just fighting so that the > output doesn't get worse. At some point, we do need to figure out a > better way of dealing with error messages, but not today :). > > Brian > > On 11/2/11 11:53 AM, "Ralph Castain" <r...@open-mpi.org> wrote: > >> Hmmm....since it was my bug that surfaced the problem, maybe the best >> answer is to just return an error code. I'll slowly work thru the param >> registrations in ORTE and make them all check the return code. I'm >> willing to look at OPAL as I go, but someone else will have to deal with >> the OMPI layer. >> >> I don't know how to entirely avoid the message issue Brian mentions - >> I'll still have to say -something- when I get an error code, but I have >> come up with some methods for reducing the clutter. >> >> On Nov 2, 2011, at 11:43 AM, Barrett, Brian W wrote: >> >>> I really don't like our show_help at every level behavior (look at what >>> happens when MPI_INIT fails, you get a page per process of the same >>> error >>> message from each level of the call stack). If you want to show_help >>> and >>> abort on debug, that makes sense. It doesn't make any sense on a >>> production build. Return an error code and let the upper layer deal >>> with >>> it. >>> >>> Brian >>> >>> On 11/2/11 11:27 AM, "Jeff Squyres" <jsquy...@cisco.com> wrote: >>> >>>> Brian: you were the one that had an allergic reaction to #1 on the >>>> call. >>>> >>>> Thoughts? >>>> >>>> >>>> On Nov 2, 2011, at 1:23 PM, George Bosilca wrote: >>>> >>>>> As it has been said, this is not something supposed to make it in a >>>>> release. On the unfortunate case where it does, always having a >>>>> show_help will ensure a quick complaint on one of our mailing lists >>>>> and >>>>> increase the probability of a [very] quick fix. >>>>> >>>>> george. >>>>> >>>>> On Nov 2, 2011, at 06:26 , TERRY DONTJE wrote: >>>>> >>>>>> >>>>>> >>>>>> On 11/1/2011 7:48 PM, Jeff Squyres wrote: >>>>>>> So this was slightly different than the opinion that was discussed >>>>>>> on >>>>>>> the call today, which was 2. The rationale for #2 was to punish >>>>>>> developers, but if such a bug did make it through to production, >>>>>>> users >>>>>>> wouldn't be annoyed with show_help messages all the time. >>>>>>> >>>>>>> Does anyone have strong opinions here? I don't. >>>>>>> >>>>>>> I offer the following two points: >>>>>>> >>>>>>> - this is a coding error on the OMPI developer >>>>>>> - it's pretty rare >>>>>>> >>>>>>> >>>>>> I think a show_help + return is very helpful in this case. I >>>>>> wouldn't >>>>>> think that we'd run into this case that much and it would seem that >>>>>> it >>>>>> would be a rare occurance that one could just fix when they run into >>>>>> it. However, since there was some opposition to having show_help >>>>>> messages possibly coming up all over the place I thought a fall >>>>>> back of only doing the show_help on enable_debug builds was a >>>>>> reasonable middle ground. >>>>>> >>>>>> --td >>>>>>> On Nov 1, 2011, at 7:30 PM, George Bosilca wrote: >>>>>>> >>>>>>> >>>>>>>> 1 >>>>>>>> >>>>>>>> george. >>>>>>>> >>>>>>>> On Nov 1, 2011, at 17:23 , Jeff Squyres wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Can you clarify -- I can parse your text multiple ways. Which are >>>>>>>>> you voting for? >>>>>>>>> >>>>>>>>> 1. show_help + return error code in all cases. >>>>>>>>> 2. if OPAL_ENABLE_DEBUG, show_help + exit(1), else silently return >>>>>>>>> error code. >>>>>>>>> 3. show_help. if OPAL_ENABLE_DEBUG, exit(1), else return error >>>>>>>>> code. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Nov 1, 2011, at 4:50 PM, George Bosilca wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> This is a much saner solution. We [mostly] stayed away from >>>>>>>>>> calling exit deep into our libraries, there is no reason to add >>>>>>>>>> it >>>>>>>>>> now. I'll vote in favor of show_help + return code. >>>>>>>>>> >>>>>>>>>> george. >>>>>>>>>> >>>>>>>>>> On Nov 1, 2011, at 15:14 , Jeff Squyres wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> We talked about this on the call today. >>>>>>>>>>> >>>>>>>>>>> A good suggestion was made: call show_help/opal_finalize/exit >>>>>>>>>>> only when OPAL_ENABLE_DEBUG is true. Otherwise, return an error >>>>>>>>>>> code. >>>>>>>>>>> >>>>>>>>>>> If no one objects to this, I'll commit this tomorrow. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Oct 31, 2011, at 4:16 PM, Jeff Squyres wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> WHAT: what to do if registering an MCA param results in an >>>>>>>>>>>> error? >>>>>>>>>>>> >>>>>>>>>>>> WHERE: opal/mca/base/mca_base_param.c >>>>>>>>>>>> >>>>>>>>>>>> WHY: MCA param re-registration issues should be treated as OMPI >>>>>>>>>>>> developer errors >>>>>>>>>>>> >>>>>>>>>>>> WHEN: COB Friday, 4 Nov 2011 >>>>>>>>>>>> >>>>>>>>>>>> ----------------- >>>>>>>>>>>> >>>>>>>>>>>> Short version: >>>>>>>>>>>> >>>>>>>>>>>> Re-registering an MCA param to be a different type (e.g., it >>>>>>>>>>>> was >>>>>>>>>>>> initially registered to be a string, but was later >>>>>>>>>>>> re-registered >>>>>>>>>>>> to be an int) should be treated as an OMPI developer error, and >>>>>>>>>>>> should opal_finalize()/exit(1). >>>>>>>>>>>> >>>>>>>>>>>> More details: >>>>>>>>>>>> >>>>>>>>>>>> A mistaken MCA param re-registration recently caused an orted >>>>>>>>>>>> segv. >>>>>>>>>>>> >>>>>>>>>>>> The MCA param subsystem was fixed to avoid this segv, but >>>>>>>>>>>> silently convert the MCA param to the newly-registered type. >>>>>>>>>>>> Upon reflection and some discussion, this seems to be a bad >>>>>>>>>>>> idea. >>>>>>>>>>>> Instead, we should loudly complain via a show_help message and >>>>>>>>>>>> then exit(1). >>>>>>>>>>>> >>>>>>>>>>>> Specifically: this kind of behavior is clearly an error and >>>>>>>>>>>> should be fixed. Unfortunately, in most cases, we don't >>>>>>>>>>>> actually >>>>>>>>>>>> check the return value from MCA param registration functions, >>>>>>>>>>>> so >>>>>>>>>>>> if we change the MCA param function to simply return a non >>>>>>>>>>>> OPAL_SUCCESS status, it's unlikely that anyone will notice >>>>>>>>>>>> until >>>>>>>>>>>> some code tries to read the param value, likely still resulting >>>>>>>>>>>> in a segv. >>>>>>>>>>>> >>>>>>>>>>>> Does anyone have heartburn if I change the error behavior to >>>>>>>>>>>> opal_finalize()/exit(1)? >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Jeff Squyres >>>>>>>>>>>> >>>>>>>>>>>> jsquy...@cisco.com >>>>>>>>>>>> >>>>>>>>>>>> For corporate legal information go to: >>>>>>>>>>>> >>>>>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> devel mailing list >>>>>>>>>>>> >>>>>>>>>>>> de...@open-mpi.org >>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>>>>>>>> -- >>>>>>>>>>> Jeff Squyres >>>>>>>>>>> >>>>>>>>>>> jsquy...@cisco.com >>>>>>>>>>> >>>>>>>>>>> For corporate legal information go to: >>>>>>>>>>> >>>>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> devel mailing list >>>>>>>>>>> >>>>>>>>>>> de...@open-mpi.org >>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>>>>>>> _______________________________________________ >>>>>>>>>> devel mailing list >>>>>>>>>> >>>>>>>>>> de...@open-mpi.org >>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>>>>>> -- >>>>>>>>> Jeff Squyres >>>>>>>>> >>>>>>>>> jsquy...@cisco.com >>>>>>>>> >>>>>>>>> For corporate legal information go to: >>>>>>>>> >>>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> devel mailing list >>>>>>>>> >>>>>>>>> de...@open-mpi.org >>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>>>>> _______________________________________________ >>>>>>>> devel mailing list >>>>>>>> >>>>>>>> de...@open-mpi.org >>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>>> >>>>>> -- >>>>>> <Mail Attachment.gif> >>>>>> Terry D. Dontje | Principal Software Engineer >>>>>> Developer Tools Engineering | +1.781.442.2631 >>>>>> Oracle - Performance Technologies >>>>>> 95 Network Drive, Burlington, MA 01803 >>>>>> Email terry.don...@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> devel mailing list >>>>>> de...@open-mpi.org >>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>>> >>>>> _______________________________________________ >>>>> devel mailing list >>>>> de...@open-mpi.org >>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>>> >>>> >>>> -- >>>> Jeff Squyres >>>> jsquy...@cisco.com >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> >>>> >>> >>> >>> -- >>> Brian W. Barrett >>> Dept. 1423: Scalable System Software >>> Sandia National Laboratories >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> > > > -- > Brian W. Barrett > Dept. 1423: Scalable System Software > Sandia National Laboratories > > > > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
