Re: [OMPI devel] Memchecker: breaks trunk again
See https://svn.open-mpi.org/trac/ompi/ticket/1276. On Apr 21, 2008, at 6:44 PM, Rainer Keller wrote: Hi Jeff and Ralph, On Monday 21 April 2008 16:48, Jeff Squyres wrote: Ah, I see what's happening. The opal/mca/memchecker/valgrind/configure.m4 file is using "want memchecker" to indicate that you want valgrind support. I think that these should be two different issues. I'll file a ticket. In opal/mca/memchecker/valgrind/configure.m4, we test if test "$WANT_MEMCHECKER" = "1" ; then ... else happy=0 # none_needed happy_value=0# none_needed memchecker_valgrind_happy=0 # This should suffice to get rid of the component should_build=2 want_component=0 fi We have been looking into other syntaxes to deselect the component, but did not find any. Is there a better way within one plugin of a component to deselect it (or rather say, that none of the components should be checked for?) Additionally, for the platform file overriding the configure command line; I *think* that that's expected behavior -- the platform file is a tradeoff and had to be implemented as an ugly hack because of the way autoconf parses command line flags (IIRC, the command line flags are parsed and *then* the platform file is parsed -- I don't think there was another way to do it). Perhaps that behavior should be documented. What's the ticket#? Sorry, if this is causing You trouble, Ralph. CU, Rainer On Apr 21, 2008, at 10:26 AM, Ralph H Castain wrote: On 4/21/08 8:10 AM, "Jeff Squyres" wrote: Hmm. I do not have this problem on OS X (where I do not have Valgrind installed) as of this morning's trunk. configure correctly determines that valgrind is not present and therefore continues on: --- MCA component memchecker:valgrind (m4 configuration macro) checking for MCA component memchecker:valgrind compile mode... static checking if MCA component memchecker:valgrind can compile... no ...etc. Note that your message indicates that configure thinks that valgrind support was explicitly requested. In this case, configure thinks, "you explicitly requested it, I cannot provide it, so I should abort rather than give unexpected results." I know that - but I am not explicitly requesting it. In fact, I explicitly put --without-valgrind, to no effect. Here is what I have discovered may be the source of the problem. I had inserted a enable_memchecker=yes line in my platform file. This apparently has the unfortunate side effect of now requiring valgrind. IMHO, this should not be setup that way per my earlier comment about requiring debuggers unless memchecker has absolutely no other way to run - which looking at the framework, would not appear to be true. I then tried still using my platform file, but adding --disable- memchecker to the configure line. The disable request was apparently ignored, at least as far as the valgrind part of the request is concerned. The build failed at the same point. Removing the enable_memchecker=yes line from my platform file allows me to successfully navigate configure. So it appears to be a combination of memchecker=yes automatically requiring valgrind, and the override on the configure line of a param set by a platform file not working. I can send you some stuff off-list in a little bit, if you still need it. Can you send your full configure output and config.log? On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote: As an FYI for anyone similarly afflicted: The only solution I have found is to gut the file opal/mca/memchecker/valgrind/configure.m4: # MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if- not- found]) # --- AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[ happy=0 # none_needed happy_value=0# none_needed memchecker_valgrind_happy=0 # This should suffice to get rid of the component should_build=2 want_component=0 ])dnl Nothing else will allow you to build unless you have the valgrind headers installed on your machine. Ralph On 4/21/08 7:28 AM, "Ralph H Castain" wrote: I am finding that the memchecker code is again breaking the trunk, specifically on any machine that does not have valgrind installed. Apparently, memchecker now forces a requirement for valgrind? Here is what I get: --- MCA component memchecker:valgrind (m4 configuration macro) checking for MCA component memchecker:valgrind compile mode... static checking checking for the valgrind include directory ... none needed checking valgrind/valgrind.h usability... no checking valgrind/valgrind.h presence... no checking for valgrind/valgrind.h... no configure: WARNING: *** Could not find valgrind header files, as valgrind support was requested configure: error: *** Cannot continue Could somebody please fix this? I thought we had decided many moons ago that we would not require s
Re: [OMPI devel] Memchecker: breaks trunk again
Hi Jeff and Ralph, On Monday 21 April 2008 16:48, Jeff Squyres wrote: > Ah, I see what's happening. > > The opal/mca/memchecker/valgrind/configure.m4 file is using "want > memchecker" to indicate that you want valgrind support. I think that > these should be two different issues. I'll file a ticket. In opal/mca/memchecker/valgrind/configure.m4, we test if test "$WANT_MEMCHECKER" = "1" ; then ... else happy=0 # none_needed happy_value=0# none_needed memchecker_valgrind_happy=0 # This should suffice to get rid of the component should_build=2 want_component=0 fi We have been looking into other syntaxes to deselect the component, but did not find any. Is there a better way within one plugin of a component to deselect it (or rather say, that none of the components should be checked for?) > Additionally, for the platform file overriding the configure command > line; I *think* that that's expected behavior -- the platform file is > a tradeoff and had to be implemented as an ugly hack because of the > way autoconf parses command line flags (IIRC, the command line flags > are parsed and *then* the platform file is parsed -- I don't think > there was another way to do it). Perhaps that behavior should be > documented. What's the ticket#? Sorry, if this is causing You trouble, Ralph. CU, Rainer > > On Apr 21, 2008, at 10:26 AM, Ralph H Castain wrote: > > On 4/21/08 8:10 AM, "Jeff Squyres" wrote: > >> Hmm. I do not have this problem on OS X (where I do not have > >> Valgrind > >> installed) as of this morning's trunk. configure correctly > >> determines > >> that valgrind is not present and therefore continues on: > >> > >> --- MCA component memchecker:valgrind (m4 configuration macro) > >> checking for MCA component memchecker:valgrind compile mode... static > >> checking if MCA component memchecker:valgrind can compile... no > >> > >> ...etc. > >> > >> Note that your message indicates that configure thinks that valgrind > >> support was explicitly requested. In this case, configure thinks, > >> "you explicitly requested it, I cannot provide it, so I should abort > >> rather than give unexpected results." > > > > I know that - but I am not explicitly requesting it. In fact, I > > explicitly > > put --without-valgrind, to no effect. > > > > Here is what I have discovered may be the source of the problem. I had > > inserted a enable_memchecker=yes line in my platform file. This > > apparently > > has the unfortunate side effect of now requiring valgrind. IMHO, > > this should > > not be setup that way per my earlier comment about requiring debuggers > > unless memchecker has absolutely no other way to run - which looking > > at the > > framework, would not appear to be true. > > > > I then tried still using my platform file, but adding --disable- > > memchecker > > to the configure line. The disable request was apparently ignored, > > at least > > as far as the valgrind part of the request is concerned. The build > > failed at > > the same point. > > > > Removing the enable_memchecker=yes line from my platform file allows > > me to > > successfully navigate configure. > > > > So it appears to be a combination of memchecker=yes automatically > > requiring > > valgrind, and the override on the configure line of a param set by a > > platform file not working. > > > > I can send you some stuff off-list in a little bit, if you still > > need it. > > > >> Can you send your full configure output and config.log? > >> > >> On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote: > >>> As an FYI for anyone similarly afflicted: > >>> > >>> The only solution I have found is to gut the file > >>> opal/mca/memchecker/valgrind/configure.m4: > >>> > >>> # MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not- > >>> found]) > >>> # --- > >>> AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[ > >>> > >>> happy=0 # none_needed > >>> happy_value=0# none_needed > >>> memchecker_valgrind_happy=0 # This should suffice to get rid > >>> of the > >>> component > >>> should_build=2 > >>> want_component=0 > >>> ])dnl > >>> > >>> Nothing else will allow you to build unless you have the valgrind > >>> headers > >>> installed on your machine. > >>> > >>> Ralph > >>> > >>> On 4/21/08 7:28 AM, "Ralph H Castain" wrote: > I am finding that the memchecker code is again breaking the trunk, > specifically on any machine that does not have valgrind installed. > Apparently, memchecker now forces a requirement for valgrind? > > Here is what I get: > > --- MCA component memchecker:valgrind (m4 configuration macro) > checking for MCA component memchecker:valgrind compile mode... > static > checking checking for the valgrind include directory ... none > needed > checking va
Re: [OMPI devel] Vprotocol build problem
Thanks, I have been looking for a way to fix this for weeks now. I'll try the POST_CONFIGURE think asap. Aurelien Le 21 avr. 08 à 10:12, Jeff Squyres a écrit : This sounds like a bug in ompi/mca/pml/v/configure.m4 that should be fixed. I'll file a ticket. FYI: AM_CONDITIONAL's cannot go in MCA_pml_c_CONFIG. See ompi/mca/ btl/ openib/configure.m4 for an example of how to do an AM_CONDITIONAL properly. On Apr 21, 2008, at 9:56 AM, Ralph H Castain wrote: I am now simply trying some of our vaunted configure system's options to see what actually works, and what doesn't. Here is one that does NOT work: enable_mca_no_build=pml-v Generates the following build error: configure: error: conditional "OMPI_BUILD_vprotocol_pessimist_DSO" was never defined. Usually this means the macro was only invoked conditionally. Could somebody please fix this? Although I know it is "on" by default, people should be able to turn it "off" - or we need to tell them "you can't". Thanks Ralph ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Memchecker: breaks trunk again
Thanks Brian - I had been told precisely the opposite priority rule just a few weeks ago by someone else, hence my confusion. On 4/21/08 8:48 AM, "Brian W. Barrett" wrote: > On Mon, 21 Apr 2008, Ralph H Castain wrote: > >> So it appears to be a combination of memchecker=yes automatically requiring >> valgrind, and the override on the configure line of a param set by a >> platform file not working. > > So I can't speak to the valgrind/memchecker issue, but can to the > platform/configure issue. The platform file was intended to provide a > mechanism to allow repeatability in builds. By design, options in the > platform file have higher priority than options given on the configure > command line. > > Brian > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Memchecker: breaks trunk again
Ah, I see what's happening. The opal/mca/memchecker/valgrind/configure.m4 file is using "want memchecker" to indicate that you want valgrind support. I think that these should be two different issues. I'll file a ticket. Additionally, for the platform file overriding the configure command line; I *think* that that's expected behavior -- the platform file is a tradeoff and had to be implemented as an ugly hack because of the way autoconf parses command line flags (IIRC, the command line flags are parsed and *then* the platform file is parsed -- I don't think there was another way to do it). Perhaps that behavior should be documented. On Apr 21, 2008, at 10:26 AM, Ralph H Castain wrote: On 4/21/08 8:10 AM, "Jeff Squyres" wrote: Hmm. I do not have this problem on OS X (where I do not have Valgrind installed) as of this morning's trunk. configure correctly determines that valgrind is not present and therefore continues on: --- MCA component memchecker:valgrind (m4 configuration macro) checking for MCA component memchecker:valgrind compile mode... static checking if MCA component memchecker:valgrind can compile... no ...etc. Note that your message indicates that configure thinks that valgrind support was explicitly requested. In this case, configure thinks, "you explicitly requested it, I cannot provide it, so I should abort rather than give unexpected results." I know that - but I am not explicitly requesting it. In fact, I explicitly put --without-valgrind, to no effect. Here is what I have discovered may be the source of the problem. I had inserted a enable_memchecker=yes line in my platform file. This apparently has the unfortunate side effect of now requiring valgrind. IMHO, this should not be setup that way per my earlier comment about requiring debuggers unless memchecker has absolutely no other way to run - which looking at the framework, would not appear to be true. I then tried still using my platform file, but adding --disable- memchecker to the configure line. The disable request was apparently ignored, at least as far as the valgrind part of the request is concerned. The build failed at the same point. Removing the enable_memchecker=yes line from my platform file allows me to successfully navigate configure. So it appears to be a combination of memchecker=yes automatically requiring valgrind, and the override on the configure line of a param set by a platform file not working. I can send you some stuff off-list in a little bit, if you still need it. Can you send your full configure output and config.log? On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote: As an FYI for anyone similarly afflicted: The only solution I have found is to gut the file opal/mca/memchecker/valgrind/configure.m4: # MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not- found]) # --- AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[ happy=0 # none_needed happy_value=0# none_needed memchecker_valgrind_happy=0 # This should suffice to get rid of the component should_build=2 want_component=0 ])dnl Nothing else will allow you to build unless you have the valgrind headers installed on your machine. Ralph On 4/21/08 7:28 AM, "Ralph H Castain" wrote: I am finding that the memchecker code is again breaking the trunk, specifically on any machine that does not have valgrind installed. Apparently, memchecker now forces a requirement for valgrind? Here is what I get: --- MCA component memchecker:valgrind (m4 configuration macro) checking for MCA component memchecker:valgrind compile mode... static checking checking for the valgrind include directory ... none needed checking valgrind/valgrind.h usability... no checking valgrind/valgrind.h presence... no checking for valgrind/valgrind.h... no configure: WARNING: *** Could not find valgrind header files, as valgrind support was requested configure: error: *** Cannot continue Could somebody please fix this? I thought we had decided many moons ago that we would not require specific debuggers in default build configurations - I am somewhat surprised, therefore, to find that memchecker is "on" by default, and now requires valgrind! I have tried --disable-memchecker, but nothing will allow me to get past this error. Thanks Ralph ___ 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 ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] Memchecker: breaks trunk again
On Mon, 21 Apr 2008, Ralph H Castain wrote: So it appears to be a combination of memchecker=yes automatically requiring valgrind, and the override on the configure line of a param set by a platform file not working. So I can't speak to the valgrind/memchecker issue, but can to the platform/configure issue. The platform file was intended to provide a mechanism to allow repeatability in builds. By design, options in the platform file have higher priority than options given on the configure command line. Brian
Re: [OMPI devel] Memchecker: breaks trunk again
On 4/21/08 8:10 AM, "Jeff Squyres" wrote: > Hmm. I do not have this problem on OS X (where I do not have Valgrind > installed) as of this morning's trunk. configure correctly determines > that valgrind is not present and therefore continues on: > > --- MCA component memchecker:valgrind (m4 configuration macro) > checking for MCA component memchecker:valgrind compile mode... static > checking if MCA component memchecker:valgrind can compile... no > > ...etc. > > Note that your message indicates that configure thinks that valgrind > support was explicitly requested. In this case, configure thinks, > "you explicitly requested it, I cannot provide it, so I should abort > rather than give unexpected results." I know that - but I am not explicitly requesting it. In fact, I explicitly put --without-valgrind, to no effect. Here is what I have discovered may be the source of the problem. I had inserted a enable_memchecker=yes line in my platform file. This apparently has the unfortunate side effect of now requiring valgrind. IMHO, this should not be setup that way per my earlier comment about requiring debuggers unless memchecker has absolutely no other way to run - which looking at the framework, would not appear to be true. I then tried still using my platform file, but adding --disable-memchecker to the configure line. The disable request was apparently ignored, at least as far as the valgrind part of the request is concerned. The build failed at the same point. Removing the enable_memchecker=yes line from my platform file allows me to successfully navigate configure. So it appears to be a combination of memchecker=yes automatically requiring valgrind, and the override on the configure line of a param set by a platform file not working. I can send you some stuff off-list in a little bit, if you still need it. > > Can you send your full configure output and config.log? > > > On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote: > >> As an FYI for anyone similarly afflicted: >> >> The only solution I have found is to gut the file >> opal/mca/memchecker/valgrind/configure.m4: >> >> # MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not- >> found]) >> # --- >> AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[ >> >>happy=0 # none_needed >>happy_value=0# none_needed >>memchecker_valgrind_happy=0 # This should suffice to get rid >> of the >> component >>should_build=2 >>want_component=0 >> ])dnl >> >> Nothing else will allow you to build unless you have the valgrind >> headers >> installed on your machine. >> >> Ralph >> >> >> >> On 4/21/08 7:28 AM, "Ralph H Castain" wrote: >> >>> I am finding that the memchecker code is again breaking the trunk, >>> specifically on any machine that does not have valgrind installed. >>> Apparently, memchecker now forces a requirement for valgrind? >>> >>> Here is what I get: >>> >>> --- MCA component memchecker:valgrind (m4 configuration macro) >>> checking for MCA component memchecker:valgrind compile mode... static >>> checking checking for the valgrind include directory ... none needed >>> checking valgrind/valgrind.h usability... no >>> checking valgrind/valgrind.h presence... no >>> checking for valgrind/valgrind.h... no >>> configure: WARNING: *** Could not find valgrind header files, as >>> valgrind >>> support was requested >>> configure: error: *** Cannot continue >>> >>> >>> Could somebody please fix this? I thought we had decided many moons >>> ago that >>> we would not require specific debuggers in default build >>> configurations - I >>> am somewhat surprised, therefore, to find that memchecker is "on" by >>> default, and now requires valgrind! >>> >>> I have tried --disable-memchecker, but nothing will allow me to get >>> past >>> this error. >>> >>> Thanks >>> Ralph >>> >>> >>> >>> >>> ___ >>> 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 >
Re: [OMPI devel] Vprotocol build problem
This sounds like a bug in ompi/mca/pml/v/configure.m4 that should be fixed. I'll file a ticket. FYI: AM_CONDITIONAL's cannot go in MCA_pml_c_CONFIG. See ompi/mca/btl/ openib/configure.m4 for an example of how to do an AM_CONDITIONAL properly. On Apr 21, 2008, at 9:56 AM, Ralph H Castain wrote: I am now simply trying some of our vaunted configure system's options to see what actually works, and what doesn't. Here is one that does NOT work: enable_mca_no_build=pml-v Generates the following build error: configure: error: conditional "OMPI_BUILD_vprotocol_pessimist_DSO" was never defined. Usually this means the macro was only invoked conditionally. Could somebody please fix this? Although I know it is "on" by default, people should be able to turn it "off" - or we need to tell them "you can't". Thanks Ralph ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] Memchecker: breaks trunk again
Hmm. I do not have this problem on OS X (where I do not have Valgrind installed) as of this morning's trunk. configure correctly determines that valgrind is not present and therefore continues on: --- MCA component memchecker:valgrind (m4 configuration macro) checking for MCA component memchecker:valgrind compile mode... static checking if MCA component memchecker:valgrind can compile... no ...etc. Note that your message indicates that configure thinks that valgrind support was explicitly requested. In this case, configure thinks, "you explicitly requested it, I cannot provide it, so I should abort rather than give unexpected results." Can you send your full configure output and config.log? On Apr 21, 2008, at 9:51 AM, Ralph H Castain wrote: As an FYI for anyone similarly afflicted: The only solution I have found is to gut the file opal/mca/memchecker/valgrind/configure.m4: # MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not- found]) # --- AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[ happy=0 # none_needed happy_value=0# none_needed memchecker_valgrind_happy=0 # This should suffice to get rid of the component should_build=2 want_component=0 ])dnl Nothing else will allow you to build unless you have the valgrind headers installed on your machine. Ralph On 4/21/08 7:28 AM, "Ralph H Castain" wrote: I am finding that the memchecker code is again breaking the trunk, specifically on any machine that does not have valgrind installed. Apparently, memchecker now forces a requirement for valgrind? Here is what I get: --- MCA component memchecker:valgrind (m4 configuration macro) checking for MCA component memchecker:valgrind compile mode... static checking checking for the valgrind include directory ... none needed checking valgrind/valgrind.h usability... no checking valgrind/valgrind.h presence... no checking for valgrind/valgrind.h... no configure: WARNING: *** Could not find valgrind header files, as valgrind support was requested configure: error: *** Cannot continue Could somebody please fix this? I thought we had decided many moons ago that we would not require specific debuggers in default build configurations - I am somewhat surprised, therefore, to find that memchecker is "on" by default, and now requires valgrind! I have tried --disable-memchecker, but nothing will allow me to get past this error. Thanks Ralph ___ 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 Cisco Systems
[OMPI devel] Vprotocol build problem
I am now simply trying some of our vaunted configure system's options to see what actually works, and what doesn't. Here is one that does NOT work: enable_mca_no_build=pml-v Generates the following build error: configure: error: conditional "OMPI_BUILD_vprotocol_pessimist_DSO" was never defined. Usually this means the macro was only invoked conditionally. Could somebody please fix this? Although I know it is "on" by default, people should be able to turn it "off" - or we need to tell them "you can't". Thanks Ralph
Re: [OMPI devel] Memchecker: breaks trunk again
As an FYI for anyone similarly afflicted: The only solution I have found is to gut the file opal/mca/memchecker/valgrind/configure.m4: # MCA_memchecker_valgrind_CONFIG([action-if-found], [action-if-not-found]) # --- AC_DEFUN([MCA_memchecker_valgrind_CONFIG],[ happy=0 # none_needed happy_value=0# none_needed memchecker_valgrind_happy=0 # This should suffice to get rid of the component should_build=2 want_component=0 ])dnl Nothing else will allow you to build unless you have the valgrind headers installed on your machine. Ralph On 4/21/08 7:28 AM, "Ralph H Castain" wrote: > I am finding that the memchecker code is again breaking the trunk, > specifically on any machine that does not have valgrind installed. > Apparently, memchecker now forces a requirement for valgrind? > > Here is what I get: > > --- MCA component memchecker:valgrind (m4 configuration macro) > checking for MCA component memchecker:valgrind compile mode... static > checking checking for the valgrind include directory ... none needed > checking valgrind/valgrind.h usability... no > checking valgrind/valgrind.h presence... no > checking for valgrind/valgrind.h... no > configure: WARNING: *** Could not find valgrind header files, as valgrind > support was requested > configure: error: *** Cannot continue > > > Could somebody please fix this? I thought we had decided many moons ago that > we would not require specific debuggers in default build configurations - I > am somewhat surprised, therefore, to find that memchecker is "on" by > default, and now requires valgrind! > > I have tried --disable-memchecker, but nothing will allow me to get past > this error. > > Thanks > Ralph > > > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] Memchecker: breaks trunk again
I am finding that the memchecker code is again breaking the trunk, specifically on any machine that does not have valgrind installed. Apparently, memchecker now forces a requirement for valgrind? Here is what I get: --- MCA component memchecker:valgrind (m4 configuration macro) checking for MCA component memchecker:valgrind compile mode... static checking checking for the valgrind include directory ... none needed checking valgrind/valgrind.h usability... no checking valgrind/valgrind.h presence... no checking for valgrind/valgrind.h... no configure: WARNING: *** Could not find valgrind header files, as valgrind support was requested configure: error: *** Cannot continue Could somebody please fix this? I thought we had decided many moons ago that we would not require specific debuggers in default build configurations - I am somewhat surprised, therefore, to find that memchecker is "on" by default, and now requires valgrind! I have tried --disable-memchecker, but nothing will allow me to get past this error. Thanks Ralph
Re: [OMPI devel] Change in btl/tcp
On Mon, Apr 21, 2008 at 09:04:28AM -0400, Josh Hursey wrote: > Adrian, Hi! > Has there been any progress on this bug? If you still cannot reproduce > it, if you send either Tim Prins or I a debugging patch we can run > with it. Or we can try to arrange access to one of our machines for you. A login would probably be the easiest. > This bug is making it difficult for us to continue working off of the > trunk since we get these connection errors so frequently. I propose the following: We (either you or me) immediately revert r18169, thus enabling you to work on the trunk again. Afterwards, I'll try to find a solution to the problem and commit it when it passes all tests on your and my clusters. I'd really appreciate a login to one or two machines at odin/sif to make sure things will be right this time. If you like, here's my ssh key: http://cluster.inf-ra.uni-jena.de/~adi/id_dsa.pub Just add it to the authorized_keys file, so no password needs to be exchanged. TIA. -- Cluster and Metacomputing Working Group Friedrich-Schiller-Universität Jena, Germany private: http://adi.thur.de
Re: [OMPI devel] Change in btl/tcp
Adrian, Has there been any progress on this bug? If you still cannot reproduce it, if you send either Tim Prins or I a debugging patch we can run with it. Or we can try to arrange access to one of our machines for you. This bug is making it difficult for us to continue working off of the trunk since we get these connection errors so frequently. -- Josh On Apr 18, 2008, at 2:26 PM, Tim Prins wrote: To echo what Josh said, there are no special compile flags being used. If you send me a patch with debug output, I'd be happy to run it for you. Both odin and sif are fairly normal linux based clusters, with ethernet and openib IP networks. The ethernet network has both ipv4 & ipv6, and the openib network runs ipv4. Tim Adrian Knoth wrote: On Fri, Apr 18, 2008 at 01:00:40PM -0400, Josh Hursey wrote: The trick is to force Open MPI to use only tcp,self and nothing else. Did you try adding this (-mca btl tcp,self) to the runtime parameter set? Sure. Even with 64 processes, I cannot trigger this behaviour. Neither on Linux nor Solaris. Any special compile flags? I guess a little bit more debug output could probably reveal the culprit. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
