Re: [OMPI devel] [patch] man and FUNC_NAME corrections
Thanks for the patch. I applied it to the trunk in r32190, and CMR (#4780)
it for the next release 1.8.2
George.
On Thu, Jul 10, 2014 at 3:09 AM, Kawashima, Takahiro <
t-kawash...@jp.fujitsu.com> wrote:
> Hi,
>
> The attached patch corrects trivial typos in man files and
> FUNC_NAME variables in ompi/mpi/c/*.c files.
>
> One note which may not be trivial:
> Before MPI-2.1, MPI standard says MPI_PACKED should be used for
> MPI_{Pack,Unpack}_external. But in MPI-2.1, it was changed to
> use MPI_BYTE. See 'B.3 Changes from Version 2.0 to Version 2.1'
> (page 766) in MPI-3.0.
>
> Though my patch is for OMPI trunk, I want to see these
> corrections in 1.8 series.
>
> Takahiro Kawashima,
> MPI development team,
> Fujitsu
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/07/15087.php
>
[OMPI devel] [patch] man and FUNC_NAME corrections
Hi,
The attached patch corrects trivial typos in man files and
FUNC_NAME variables in ompi/mpi/c/*.c files.
One note which may not be trivial:
Before MPI-2.1, MPI standard says MPI_PACKED should be used for
MPI_{Pack,Unpack}_external. But in MPI-2.1, it was changed to
use MPI_BYTE. See 'B.3 Changes from Version 2.0 to Version 2.1'
(page 766) in MPI-3.0.
Though my patch is for OMPI trunk, I want to see these
corrections in 1.8 series.
Takahiro Kawashima,
MPI development team,
Fujitsu
Index: ompi/mpi/c/message_c2f.c
===
--- ompi/mpi/c/message_c2f.c (revision 32173)
+++ ompi/mpi/c/message_c2f.c (working copy)
@@ -35,7 +35,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_Message_f2c";
+static const char FUNC_NAME[] = "MPI_Message_c2f";
MPI_Fint MPI_Message_c2f(MPI_Message message)
Index: ompi/mpi/c/get_accumulate.c
===
--- ompi/mpi/c/get_accumulate.c (revision 32173)
+++ ompi/mpi/c/get_accumulate.c (working copy)
@@ -41,7 +41,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_Get_accumlate";
+static const char FUNC_NAME[] = "MPI_Get_accumulate";
int MPI_Get_accumulate(const void *origin_addr, int origin_count, MPI_Datatype origin_datatype,
void *result_addr, int result_count, MPI_Datatype result_datatype,
Index: ompi/mpi/c/rget_accumulate.c
===
--- ompi/mpi/c/rget_accumulate.c (revision 32173)
+++ ompi/mpi/c/rget_accumulate.c (working copy)
@@ -42,7 +42,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_Rget_accumlate";
+static const char FUNC_NAME[] = "MPI_Rget_accumulate";
int MPI_Rget_accumulate(const void *origin_addr, int origin_count, MPI_Datatype origin_datatype,
void *result_addr, int result_count, MPI_Datatype result_datatype,
Index: ompi/mpi/c/request_c2f.c
===
--- ompi/mpi/c/request_c2f.c (revision 32173)
+++ ompi/mpi/c/request_c2f.c (working copy)
@@ -35,7 +35,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_Request_f2c";
+static const char FUNC_NAME[] = "MPI_Request_c2f";
MPI_Fint MPI_Request_c2f(MPI_Request request)
Index: ompi/mpi/c/raccumulate.c
===
--- ompi/mpi/c/raccumulate.c (revision 32173)
+++ ompi/mpi/c/raccumulate.c (working copy)
@@ -41,7 +41,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_Accumlate";
+static const char FUNC_NAME[] = "MPI_Raccumulate";
int MPI_Raccumulate(void *origin_addr, int origin_count, MPI_Datatype origin_datatype,
int target_rank, MPI_Aint target_disp, int target_count,
Index: ompi/mpi/c/unpack_external.c
===
--- ompi/mpi/c/unpack_external.c (revision 32173)
+++ ompi/mpi/c/unpack_external.c (working copy)
@@ -37,7 +37,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_Unpack_external ";
+static const char FUNC_NAME[] = "MPI_Unpack_external";
int MPI_Unpack_external (const char datarep[], const void *inbuf, MPI_Aint insize,
Index: ompi/mpi/c/comm_size.c
===
--- ompi/mpi/c/comm_size.c (revision 32173)
+++ ompi/mpi/c/comm_size.c (working copy)
@@ -35,7 +35,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_comm_size";
+static const char FUNC_NAME[] = "MPI_Comm_size";
int MPI_Comm_size(MPI_Comm comm, int *size)
Index: ompi/mpi/c/get_library_version.c
===
--- ompi/mpi/c/get_library_version.c (revision 32173)
+++ ompi/mpi/c/get_library_version.c (working copy)
@@ -31,7 +31,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_get_library_version";
+static const char FUNC_NAME[] = "MPI_Get_library_version";
int MPI_Get_library_version(char *version, int *resultlen)
Index: ompi/mpi/c/ireduce_scatter_block.c
===
--- ompi/mpi/c/ireduce_scatter_block.c (revision 32173)
+++ ompi/mpi/c/ireduce_scatter_block.c (working copy)
@@ -39,7 +39,7 @@
#include "ompi/mpi/c/profile/defines.h"
#endif
-static const char FUNC_NAME[] = "MPI_Reduce_scatter_block";
+static const char FUNC_NAME[] = "MPI_Ireduce_scatter_block";
int MPI_Ireduce_scatter_block(const void *sendbuf, void *recvbuf, int recvcount,
Index: ompi/mpi/man/man3/MPI_Pack_external.3in
===
--- ompi/mpi/man/man3/MPI_Pack_external.3in (revisio
Re: [OMPI devel] segv in ompi_info
Good suggestion - fixed on trunk in r32189 On Jul 9, 2014, at 2:30 PM, Paul Hargrove wrote: > I agree with Gilles that there is not a "bug", but I believe that OMPI could > do something better. > > First, I'll show that > a) this is not a new behavior > b) it is not limited to "less". > > $ (strace ompi_info -a | grep -m1 btl) 2>&1 | grep -e 'Open MPI:' -e SIGPIPE > write(1, "Open MPI: 1.4.5\n", 32) = 32 > --- SIGPIPE (Broken pipe) @ 0 (0) --- > +++ killed by SIGPIPE +++ > > a) the opmi_info output says "Open MPI: 1.4.5" (thus not new by any stretch). > b) the "-m1" argument to the inner "grep" says exit after the first match > > The "strace" is to detect/report that SIGPIPE was received. > The outer grep picks out the relevant info from the flood of strace output. > > So, the "issue" today seems to be that mxm is catching the signal and > producing a backtrace. This backtrace is NOT a desirable behavior. This is > not intrinsically the "fault" of mxm, because there is no reason to believe > that ompi_info would never link to (or dlopen) another library that performs > backtraces. > > So, I would suggest that ompi_info simply "signal(SIGPIPE, SIG_IGN);" to > resolve this in a way not specific to mxm. > > -Paul > > > On Wed, Jul 9, 2014 at 3:47 AM, Gilles Gouaillardet > wrote: > Mike, > > how do you test ? > i cannot reproduce a bug : > > if you run ompi_info -a -l 9 | less > > and i press 'q' at the early stage (e.g. before all output is written to the > pipe) > then the less process exits and receives SIG_PIPE and crash (which is a > normal unix behaviour) > > now if i press the spacebar until the end of the output (e.g. i get the (END) > message from less) > and then press 'q', then there is no problem. > > strace -e signal ompi_info -a -l 9 | true > will cause ompi_info receives a SIG_PIPE > > strace -e signal dd if=/dev/zero bs=1M count=1 | true > will cause dd receives a SIG_PIPE > > unless i miss something, i would conclude there is no bug > > Cheers, > > Gilles > > On 2014/07/09 19:33, Mike Dubman wrote: >> mxm only intercept signals and prints the stacktrace. >> happens on trunk as well. >> only when "| less" is used. >> >> >> >> >> >> >> On Tue, Jul 8, 2014 at 4:50 PM, Jeff Squyres (jsquyres) >> wrote: >> >>> I'm unable to replicate. Please provide more detail...? Is this a >>> problem in the MXM component? >>> >>> On Jul 8, 2014, at 9:20 AM, Mike Dubman wrote: >>> $/usr/mpi/gcc/openmpi-1.8.2a1/bin/ompi_info -a -l 9|less Caught signal 13 (Broken pipe) backtrace 2 0x00054cac mxm_handle_error() >>> /var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:653 3 0x00054e74 mxm_error_signal_handler() >>> /var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:628 4 0x0033fbe32920 killpg() ??:0 5 0x0033fbedb650 __write_nocancel() interp.c:0 6 0x0033fbe71d53 _IO_file_write@@GLIBC_2.2.5() ??:0 7 0x0033fbe73305 _IO_do_write@@GLIBC_2.2.5() ??:0 8 0x0033fbe719cd _IO_file_xsputn@@GLIBC_2.2.5() ??:0 9 0x0033fbe48410 _IO_vfprintf() ??:0 10 0x0033fbe4f40a printf() ??:0 11 0x0002bc84 opal_info_out() >>> >>> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:853 12 0x0002c6bb opal_info_show_mca_group_params() >>> >>> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:658 13 0x0002c882 opal_info_show_mca_group_params() >>> >>> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:716 14 0x0002cc13 opal_info_show_mca_params() >>> >>> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:742 15 0x0002d074 opal_info_do_params() >>> >>> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:485 16 0x0040167b main() ??:0 17 0x0033fbe1ecdd __libc_start_main() ??:0 18 0x00401349 _start() ??:0 === ___ devel mailing list de...@open-mpi.org Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post: >>> http://www.open-mpi.org/community/lists/devel/2014/07/15075.php >>> >>> >>> -- >>> 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 >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >>> http://www.open-mpi.org/community/lists/devel/2014/07/15076.php >>> >> >> >> ___ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post:
Re: [OMPI devel] segv in ompi_info
I agree with Gilles that there is not a "bug", but I believe that OMPI could do something better. First, I'll show that a) this is not a new behavior b) it is not limited to "less". $ (strace ompi_info -a | grep -m1 btl) 2>&1 | grep -e 'Open MPI:' -e SIGPIPE write(1, "Open MPI: 1.4.5\n", 32) = 32 --- SIGPIPE (Broken pipe) @ 0 (0) --- +++ killed by SIGPIPE +++ a) the opmi_info output says "Open MPI: 1.4.5" (thus not new by any stretch). b) the "-m1" argument to the inner "grep" says exit after the first match The "strace" is to detect/report that SIGPIPE was received. The outer grep picks out the relevant info from the flood of strace output. So, the "issue" today seems to be that mxm is catching the signal and producing a backtrace. This backtrace is NOT a desirable behavior. This is not intrinsically the "fault" of mxm, because there is no reason to believe that ompi_info would never link to (or dlopen) another library that performs backtraces. So, I would suggest that ompi_info simply "signal(SIGPIPE, SIG_IGN);" to resolve this in a way not specific to mxm. -Paul On Wed, Jul 9, 2014 at 3:47 AM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: > Mike, > > how do you test ? > i cannot reproduce a bug : > > if you run ompi_info -a -l 9 | less > > and i press 'q' at the early stage (e.g. before all output is written to > the pipe) > then the less process exits and receives SIG_PIPE and crash (which is a > normal unix behaviour) > > now if i press the spacebar until the end of the output (e.g. i get the > (END) message from less) > and then press 'q', then there is no problem. > > strace -e signal ompi_info -a -l 9 | true > will cause ompi_info receives a SIG_PIPE > > strace -e signal dd if=/dev/zero bs=1M count=1 | true > will cause dd receives a SIG_PIPE > > unless i miss something, i would conclude there is no bug > > Cheers, > > Gilles > > On 2014/07/09 19:33, Mike Dubman wrote: > > mxm only intercept signals and prints the stacktrace. > happens on trunk as well. > only when "| less" is used. > > > > > > > On Tue, Jul 8, 2014 at 4:50 PM, Jeff Squyres (jsquyres) > > wrote: > > > I'm unable to replicate. Please provide more detail...? Is this a > problem in the MXM component? > > On Jul 8, 2014, at 9:20 AM, Mike Dubman > wrote: > > > > $/usr/mpi/gcc/openmpi-1.8.2a1/bin/ompi_info -a -l 9|less > Caught signal 13 (Broken pipe) > backtrace > 2 0x00054cac mxm_handle_error() > > /var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:653 > > 3 0x00054e74 mxm_error_signal_handler() > > /var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:628 > > 4 0x0033fbe32920 killpg() ??:0 > 5 0x0033fbedb650 __write_nocancel() interp.c:0 > 6 0x0033fbe71d53 _IO_file_write@@GLIBC_2.2.5() ??:0 > 7 0x0033fbe73305 _IO_do_write@@GLIBC_2.2.5() ??:0 > 8 0x0033fbe719cd _IO_file_xsputn@@GLIBC_2.2.5() ??:0 > 9 0x0033fbe48410 _IO_vfprintf() ??:0 > 10 0x0033fbe4f40a printf() ??:0 > 11 0x0002bc84 opal_info_out() > > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:853 > > 12 0x0002c6bb opal_info_show_mca_group_params() > > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:658 > > 13 0x0002c882 opal_info_show_mca_group_params() > > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:716 > > 14 0x0002cc13 opal_info_show_mca_params() > > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:742 > > 15 0x0002d074 opal_info_do_params() > > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:485 > > 16 0x0040167b main() ??:0 > 17 0x0033fbe1ecdd __libc_start_main() ??:0 > 18 0x00401349 _start() ??:0 > === > ___ > devel mailing listde...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > > http://www.open-mpi.org/community/lists/devel/2014/07/15075.php > > > -- > Jeff squyresjsquy...@cisco.com > For corporate legal information go > to:http://www.cisco.com/web/about/doing_business/legal/cri/ > > ___ > devel mailing listde...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this > post:http://www.open-mpi.org/community/lists/devel/2014/07/15076.php > > > > ___ > devel mailing listde...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15080.php > > > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi
Re: [OMPI devel] Shared library version numbers for 1.8.2
Ouch - yes, we definitely should roll it to 4:0:0. I gather the ABI change was required to comply with the spec. I normally would refuse to allow an ABI change during a stable release series, but have given more latitude to OSHMEM due to its relatively new inclusion and the need to get it into compliance. On Jul 9, 2014, at 1:25 PM, Bert Wesarg wrote: > Quoting "Jeff Squyres (jsquyres)" : >> Here's what I think VERSION should be for 1.8.2: >> >>https://svn.open-mpi.org/trac/ompi/changeset/32165 >> >> I left comments in the VERSION file as to why I think each version number >> should change. >> >> Can someone please verify that this work is correct? If so, we can remove >> the comments (before the final 1.8.2 release). > >> -liboshmem_so_version=2:0:1 >> +liboshmem_so_version=3:0:2 >> +# lib changed >> +# added interfaces: shmem_int32_finc, shmem_int64_finc, profiling > > I think liboshmem_so_version should get 4:0:0 as the return type of > shmem_finalize changed from int to void. > > Here is the trunk commit: > > https://svn.open-mpi.org/trac/ompi/changeset/31413 > > And here the CMR commit: > > https://svn.open-mpi.org/trac/ompi/changeset/31758 > > Regards, > Bert > >> >> -- >> Jeff Squyres > -- > Dipl.-Inf. Bert Wesarg > wiss. Mitarbeiter > > Technische Universität Dresden > Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) > 01062 Dresden > Tel.: +49 (351) 463-42451 > Fax: +49 (351) 463-37773 > E-Mail: bert.wes...@tu-dresden.de > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15083.php
Re: [OMPI devel] Shared library version numbers for 1.8.2
Quoting "Jeff Squyres (jsquyres)" : Here's what I think VERSION should be for 1.8.2: https://svn.open-mpi.org/trac/ompi/changeset/32165 I left comments in the VERSION file as to why I think each version number should change. Can someone please verify that this work is correct? If so, we can remove the comments (before the final 1.8.2 release). -liboshmem_so_version=2:0:1 +liboshmem_so_version=3:0:2 +# lib changed +# added interfaces: shmem_int32_finc, shmem_int64_finc, profiling I think liboshmem_so_version should get 4:0:0 as the return type of shmem_finalize changed from int to void. Here is the trunk commit: https://svn.open-mpi.org/trac/ompi/changeset/31413 And here the CMR commit: https://svn.open-mpi.org/trac/ompi/changeset/31758 Regards, Bert -- Jeff Squyres -- Dipl.-Inf. Bert Wesarg wiss. Mitarbeiter Technische Universität Dresden Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) 01062 Dresden Tel.: +49 (351) 463-42451 Fax: +49 (351) 463-37773 E-Mail: bert.wes...@tu-dresden.de
Re: [OMPI devel] segv in ompi_info
Mike, how do you test ? i cannot reproduce a bug : if you run ompi_info -a -l 9 | less and i press 'q' at the early stage (e.g. before all output is written to the pipe) then the less process exits and receives SIG_PIPE and crash (which is a normal unix behaviour) now if i press the spacebar until the end of the output (e.g. i get the (END) message from less) and then press 'q', then there is no problem. strace -e signal ompi_info -a -l 9 | true will cause ompi_info receives a SIG_PIPE strace -e signal dd if=/dev/zero bs=1M count=1 | true will cause dd receives a SIG_PIPE unless i miss something, i would conclude there is no bug Cheers, Gilles On 2014/07/09 19:33, Mike Dubman wrote: > mxm only intercept signals and prints the stacktrace. > happens on trunk as well. > only when "| less" is used. > > > > > > > On Tue, Jul 8, 2014 at 4:50 PM, Jeff Squyres (jsquyres) > wrote: > >> I'm unable to replicate. Please provide more detail...? Is this a >> problem in the MXM component? >> >> On Jul 8, 2014, at 9:20 AM, Mike Dubman wrote: >> >>> >>> $/usr/mpi/gcc/openmpi-1.8.2a1/bin/ompi_info -a -l 9|less >>> Caught signal 13 (Broken pipe) >>> backtrace >>> 2 0x00054cac mxm_handle_error() >> /var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:653 >>> 3 0x00054e74 mxm_error_signal_handler() >> /var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:628 >>> 4 0x0033fbe32920 killpg() ??:0 >>> 5 0x0033fbedb650 __write_nocancel() interp.c:0 >>> 6 0x0033fbe71d53 _IO_file_write@@GLIBC_2.2.5() ??:0 >>> 7 0x0033fbe73305 _IO_do_write@@GLIBC_2.2.5() ??:0 >>> 8 0x0033fbe719cd _IO_file_xsputn@@GLIBC_2.2.5() ??:0 >>> 9 0x0033fbe48410 _IO_vfprintf() ??:0 >>> 10 0x0033fbe4f40a printf() ??:0 >>> 11 0x0002bc84 opal_info_out() >> >> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:853 >>> 12 0x0002c6bb opal_info_show_mca_group_params() >> >> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:658 >>> 13 0x0002c882 opal_info_show_mca_group_params() >> >> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:716 >>> 14 0x0002cc13 opal_info_show_mca_params() >> >> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:742 >>> 15 0x0002d074 opal_info_do_params() >> >> /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:485 >>> 16 0x0040167b main() ??:0 >>> 17 0x0033fbe1ecdd __libc_start_main() ??:0 >>> 18 0x00401349 _start() ??:0 >>> === >>> ___ >>> devel mailing list >>> de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/07/15075.php >> >> >> -- >> 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 >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/07/15076.php >> > > > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15080.php
Re: [OMPI devel] trunk and fortran errors
@#%$#@!$% This is almost certainly due to r32162 (Fortran commit from last night). I'm offline most of today; I won't be able to look at this until tonight at the earliest, sorry. :-( For the moment/as a workaround, use --disable-mpi-fortran in your builds if you are building with an older gfortran. On Jul 9, 2014, at 6:33 AM, Mike Dubman wrote: > > Hi, > The latest svn/trunks fails to install on centos 5.7,5.8,5.9 but works fine > on others. > > after: > > ./configure --with-platform=contrib/platform/mellanox/optimized > --with-knem=/opt/knem-0.9.7mlnx1 --with-fca=/opt/mellanox/fca > --with-ompi-param-check --enable-picky > --prefix=/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi_install1 > && make clean && make install > > errors during "make install": > > 10:58:23 > /bin/mkdir -p > '/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi_install1/include/openmpi/ompi/mpi/fortran/mpif-h' > > 10:58:23 > /usr/bin/install -c -m 644 bindings.h prototypes_mpi.h status-conversion.h > '/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi_install1/include/openmpi/ompi/mpi/fortran/mpif-h' > > 10:58:23 > make[4]: Leaving directory > `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/mpif-h' > > 10:58:23 > make[3]: Leaving directory > `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/mpif-h' > > 10:58:23 > make[2]: Leaving directory > `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/mpif-h' > > 10:58:23 > Making install in mpi/fortran/use-mpi-tkr > > 10:58:23 > make[2]: Entering directory > `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/use-mpi-tkr' > > 10:58:23 > PPFC mpi.lo > > 10:58:25 > In file mpi-f90-interfaces.h:2900 > > 10:58:25 > 10:58:25 > Included at mpi.F90:45 > > 10:58:25 > 10:58:25 > use, intrinsic :: iso_c_binding, only : c_ptr > > 10:58:25 > 1 > > 10:58:25 > Error: Unclassifiable statement at (1) > > 10:58:25 > In file mpi-f90-interfaces.h:2904 > > 10:58:25 > 10:58:25 > Included at mpi.F90:45 > > 10:58:25 > 10:58:25 > type(C_PTR) :: baseptr > > 10:58:25 > 1 > > 10:58:25 > Error: Derived type 'c_ptr' at (1) is being used before it is defined > > 10:58:25 > In file mpi-f90-interfaces.h:3121 > > 10:58:25 > 10:58:25 > Included at mpi.F90:45 > > 10:58:25 > 10:58:25 > use, intrinsic :: iso_c_binding, only : c_ptr > > 10:58:25 > 1 > > 10:58:25 > Error: Unclassifiable statement at (1) > > 10:58:25 > In file mpi-f90-interfaces.h:3127 > > 10:58:25 > 10:58:25 > Included at mpi.F90:45 > > 10:58:25 > 10:58:25 > type(C_PTR), intent(out) :: baseptr > > 10:58:25 > 1 > > 10:58:25 > Error: Derived type 'c_ptr' at (1) is being used before it is defined > > 10:58:25 > make[2]: *** [mpi.lo] Error 1 > > 10:58:25 > make[2]: Leaving directory > `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/use-mpi-tkr' > > 10:58:25 make[1]: *** [install-recursive] Error 1 > ___ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15079.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] segv in ompi_info
mxm only intercept signals and prints the stacktrace. happens on trunk as well. only when "| less" is used. On Tue, Jul 8, 2014 at 4:50 PM, Jeff Squyres (jsquyres) wrote: > I'm unable to replicate. Please provide more detail...? Is this a > problem in the MXM component? > > On Jul 8, 2014, at 9:20 AM, Mike Dubman wrote: > > > > > > > $/usr/mpi/gcc/openmpi-1.8.2a1/bin/ompi_info -a -l 9|less > > Caught signal 13 (Broken pipe) > > backtrace > > 2 0x00054cac mxm_handle_error() > /var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:653 > > 3 0x00054e74 mxm_error_signal_handler() > /var/tmp/OFED_topdir/BUILD/mxm-3.2.2883/src/mxm/util/debug/debug.c:628 > > 4 0x0033fbe32920 killpg() ??:0 > > 5 0x0033fbedb650 __write_nocancel() interp.c:0 > > 6 0x0033fbe71d53 _IO_file_write@@GLIBC_2.2.5() ??:0 > > 7 0x0033fbe73305 _IO_do_write@@GLIBC_2.2.5() ??:0 > > 8 0x0033fbe719cd _IO_file_xsputn@@GLIBC_2.2.5() ??:0 > > 9 0x0033fbe48410 _IO_vfprintf() ??:0 > > 10 0x0033fbe4f40a printf() ??:0 > > 11 0x0002bc84 opal_info_out() > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:853 > > 12 0x0002c6bb opal_info_show_mca_group_params() > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:658 > > 13 0x0002c882 opal_info_show_mca_group_params() > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:716 > > 14 0x0002cc13 opal_info_show_mca_params() > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:742 > > 15 0x0002d074 opal_info_do_params() > > /var/tmp/OFED_topdir/BUILD/openmpi-1.8.2a1/opal/runtime/opal_info_support.c:485 > > 16 0x0040167b main() ??:0 > > 17 0x0033fbe1ecdd __libc_start_main() ??:0 > > 18 0x00401349 _start() ??:0 > > === > > ___ > > devel mailing list > > de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15075.php > > > -- > 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 > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/07/15076.php >
[OMPI devel] trunk and fortran errors
Hi, The latest svn/trunks fails to install on centos 5.7,5.8,5.9 but works fine on others. after: ./configure --with-platform=contrib/platform/mellanox/optimized --with-knem=/opt/knem-0.9.7mlnx1 --with-fca=/opt/mellanox/fca --with-ompi-param-check --enable-picky --prefix=/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi_install1 && make clean && make install errors during "make install": *10:58:23* /bin/mkdir -p '/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi_install1/include/openmpi/ompi/mpi/fortran/mpif-h'*10:58:23* /usr/bin/install -c -m 644 bindings.h prototypes_mpi.h status-conversion.h '/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi_install1/include/openmpi/ompi/mpi/fortran/mpif-h'*10:58:23* make[4]: Leaving directory `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/mpif-h'*10:58:23* make[3]: Leaving directory `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/mpif-h'*10:58:23* make[2]: Leaving directory `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/mpif-h'*10:58:23* Making install in mpi/fortran/use-mpi-tkr*10:58:23* make[2]: Entering directory `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/use-mpi-tkr'*10:58:23* PPFC mpi.lo*10:58:25* In file mpi-f90-interfaces.h:2900*10:58:25* *10:58:25* Included at mpi.F90:45*10:58:25* *10:58:25* use, intrinsic :: iso_c_binding, only : c_ptr*10:58:25* 1*10:58:25* Error: Unclassifiable statement at (1)*10:58:25* In file mpi-f90-interfaces.h:2904*10:58:25* *10:58:25* Included at mpi.F90:45*10:58:25* *10:58:25* type(C_PTR) :: baseptr*10:58:25* 1*10:58:25* Error: Derived type 'c_ptr' at (1) is being used before it is defined*10:58:25* In file mpi-f90-interfaces.h:3121*10:58:25* *10:58:25* Included at mpi.F90:45*10:58:25* *10:58:25* use, intrinsic :: iso_c_binding, only : c_ptr*10:58:25* 1*10:58:25* Error: Unclassifiable statement at (1)*10:58:25* In file mpi-f90-interfaces.h:3127*10:58:25* *10:58:25* Included at mpi.F90:45*10:58:25* *10:58:25* type(C_PTR), intent(out) :: baseptr*10:58:25* 1*10:58:25* Error: Derived type 'c_ptr' at (1) is being used before it is defined*10:58:25* make[2]: *** [mpi.lo] Error 1*10:58:25* make[2]: Leaving directory `/scrap/jenkins/workspace/hpc-ompi-shmem-2/label/r-vmb-centos5-u7-x86-64/ompi/mpi/fortran/use-mpi-tkr'*10:58:25* make[1]: *** [install-recursive] Error 1
