- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPI and signal handlers
by Darius Buntinas 28 Nov '12

28 Nov '12

Sorry, MPICH doesn't allow MPI calls from signal handlers. -d On Nov 28, 2012, at 8:54 AM, Matthieu Dorier wrote: > Hello, > > I read in the MPI-3 standard that allowing MPI calls within signal handlers is implementation dependent (I guess it's the same in previous standards). > Does mpich allow MPI calls within signal handlers? > > Also which signals are used by mpich? Does mpich use SIGSEGV? > > Thank you, > > Matthieu Dorier > PhD student at ENS Cachan Brittany and IRISA > http://people.irisa.fr/Matthieu.Dorier > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] using MPICH_FAILED_PROCESSES
by Darius Buntinas 28 Nov '12

28 Nov '12

Hi Zhaoming, Leave the default error handler set so that an error gets printed, then try it again and send us the output. -d On Nov 27, 2012, at 3:27 PM, Ma, Zhaoming wrote: > I am trying to use the following to catch failed processes, > > MPI::COMM_WORLD.Get_attr(MPICH_ATTR_FAILED_PROCESSES, void*) > > I am using MPICH2 1.4 and g++. Someone posted a C program that does this successfully. The link is http://hi.baidu.com/ejoywx/item/74233ccb9dd20815515058ae. However, I am having trouble making my C++ testing program (attached) working. The code compiled ok but produces the following runtime error, > > terminate called after throwing an instance of 'MPI::Exception' > APPLICATION TERMINATED WITH THE EXIT STRING: Aborted (signal 6) > > If I comment out the line "MPI::COMM_WORLD.Get_attr(MPICH_ATTR_FAILED_PROCESSES, void*)" or put it in a try and catch block, the test program runs fine. > > Thank you for your help. > > Zhaoming > <MPI_test.cpp.txt>_______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPI and signal handlers
by Matthieu Dorier 28 Nov '12

28 Nov '12

Hello, I read in the MPI-3 standard that allowing MPI calls within signal handlers is implementation dependent (I guess it's the same in previous standards) . Does mpich allow MPI calls within signal handlers? Also which signals are used by mpich? Does mpich use SIGSEGV? Thank you, Matthieu Dorier PhD student at ENS Cachan Brittany and IRISA http://people.irisa.fr/Matthieu.Dorier

1 0

Re: [mpich-discuss] How to specify number of cores for each process
by Pavan Balaji 28 Nov '12

28 Nov '12

On 11/28/2012 07:41 AM US Central Time, Pavan Balaji wrote: > 2. There's option called -binding auto. Did you mean -binding none? Gah. I meant, there's *no* option called -binding auto. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] How to specify number of cores for each process
by Pavan Balaji 28 Nov '12

28 Nov '12

As Zachary explained below, each process is in a different directory, so he'll need to use an MPMD launch and can't do -n 16 directly. -- Pavan On 11/27/2012 09:42 PM US Central Time, Jeff Hammond wrote: > Did you try "mpiexec -n 16 ..."? > > Sent from my iPhone > > On Nov 27, 2012, at 10:37 PM, Zachary Stanko <zstanko(a)usgs.gov > <mailto:[email protected]>> wrote: > >> Hello, >> >> I am running an MPI program on a machine with two 16-core processors >> yet, no matter what configuration I use with mpiexec, I am only >> receiving 4 simultaneous processes. >> I would like to maximize this machine's potential and run 8 or 16 >> processes. I have tried all of the channel selections and tried the >> -binding option. >> Since I need to specify a different working directory for each process >> (due to many output files with naming conflicts), I have a config file >> with 8 lines of the form: >> >> -n 1 -binding auto -dir <mydir01> <myprog> <inpfile> >> -n 1 -binding auto -dir <mydir02> <myprog> <inpfile> >> ...etc >> >> and I run: >> >> mpiexec -configfile <filename> >> >> Am I doing something wrong, or does MPICH just know best and cannot >> run more than 4 jobs at a time on this system? >> >> Thanks, >> >> Zak >> _______________________________________________ >> discuss mailing list <mailto:[email protected]>discuss(a)mpich.org >> <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] How to specify number of cores for each process
by Pavan Balaji 28 Nov '12

28 Nov '12

There are two problems in your usage below. 1. I'm guessing that your host file specifies only one core for each host. Something like: host1 host2 Did you look through the mpiexec usage document that tells you how to specify multiple cores on each host? http://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager You should do something like: host1:16 host2:16 (please read the documentation on the above link for more information). 2. There's option called -binding auto. Did you mean -binding none? -- Pavan On 11/27/2012 09:37 PM US Central Time, Zachary Stanko wrote: > Hello, > > I am running an MPI program on a machine with two 16-core processors > yet, no matter what configuration I use with mpiexec, I am only > receiving 4 simultaneous processes. > I would like to maximize this machine's potential and run 8 or 16 > processes. I have tried all of the channel selections and tried the > -binding option. > Since I need to specify a different working directory for each process > (due to many output files with naming conflicts), I have a config file > with 8 lines of the form: > > -n 1 -binding auto -dir <mydir01> <myprog> <inpfile> > -n 1 -binding auto -dir <mydir02> <myprog> <inpfile> > ...etc > > and I run: > > mpiexec -configfile <filename> > > Am I doing something wrong, or does MPICH just know best and cannot run > more than 4 jobs at a time on this system? > > Thanks, > > Zak > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] How to specify number of cores for each process
by Jeff Hammond 27 Nov '12

27 Nov '12

Did you try "mpiexec -n 16 ..."? Sent from my iPhone On Nov 27, 2012, at 10:37 PM, Zachary Stanko <zstanko(a)usgs.gov> wrote: Hello, I am running an MPI program on a machine with two 16-core processors yet, no matter what configuration I use with mpiexec, I am only receiving 4 simultaneous processes. I would like to maximize this machine's potential and run 8 or 16 processes. I have tried all of the channel selections and tried the -binding option. Since I need to specify a different working directory for each process (due to many output files with naming conflicts), I have a config file with 8 lines of the form: -n 1 -binding auto -dir <mydir01> <myprog> <inpfile> -n 1 -binding auto -dir <mydir02> <myprog> <inpfile> ...etc and I run: mpiexec -configfile <filename> Am I doing something wrong, or does MPICH just know best and cannot run more than 4 jobs at a time on this system? Thanks, Zak _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

How to specify number of cores for each process
by Zachary Stanko 27 Nov '12

27 Nov '12

Hello, I am running an MPI program on a machine with two 16-core processors yet, no matter what configuration I use with mpiexec, I am only receiving 4 simultaneous processes. I would like to maximize this machine's potential and run 8 or 16 processes. I have tried all of the channel selections and tried the -binding option. Since I need to specify a different working directory for each process (due to many output files with naming conflicts), I have a config file with 8 lines of the form: -n 1 -binding auto -dir <mydir01> <myprog> <inpfile> -n 1 -binding auto -dir <mydir02> <myprog> <inpfile> ...etc and I run: mpiexec -configfile <filename> Am I doing something wrong, or does MPICH just know best and cannot run more than 4 jobs at a time on this system? Thanks, Zak

1 0

Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5
by Dave Goodell 27 Nov '12

27 Nov '12

I've created a ticket to track this, although I have no idea when we might get around to actually implementing a workaround for broken RHEL 5.5: http://trac.mpich.org/projects/mpich/ticket/1760 -Dave On Nov 27, 2012, at 3:17 PM CST, Yauheni Zelenko wrote: > Hi, Dave! > > I played with preprocessor output aand it looks like this is problem of RHEL 5.5. > > _FILE_OFFSET_BITS=64 forces to redirect stat/fstat to their 64 bit counterparts (with __asm__) . > > _LARGEFILE64_SOURCE defines stat/fstat/stat64/fstat64. > > So combination of both will cause redefinition of stat64/fstat64. > > BTW _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64 appear twice in compiler command line. > > Eugene. > ________________________________________ > From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] > Sent: Wednesday, November 21, 2012 10:38 AM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 > > Hi Eugene, > > I was not able to reproduce this behavior on RHEL 5.8 with gcc-4.1 or gcc-4.6 (though I was able to reproduce the earlier LLONG_MAX issue). > > Would you please dig in here and debug a bit for us? It seems that there is something very specific about your environment and/or compiler that is causing a problem here. > > -Dave > > On Nov 20, 2012, at 7:07 PM CST, Yauheni Zelenko wrote: > >> Your guess is correct. Compilation is fine when only one of defines left in command line. >> >> You could try to install CentOS which is copy of RHEL. >> >> Alternatively, I could send files in questions. >> >> Eugene. >> ________________________________________ >> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >> Sent: Tuesday, November 20, 2012 4:57 PM >> To: discuss(a)mpich.org >> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >> >> My suspicion is that it is more likely related to the following arguments: >> >> ----8<---- >> -D_LARGEFILE64_SOURCE >> -D_FILE_OFFSET_BITS=64 >> ----8<---- >> >> Can you try running that same gcc command from the build directory's "src/mpi/romio" directory but with omitting various combinations of the two above options? >> >> Reading the source of feature.h and/or stat.h would probably also help, although I do not have a RHEL5/6 system handy. >> >> -Dave >> >> On Nov 20, 2012, at 6:09 PM CST, Yauheni Zelenko wrote: >> >>> Hi, Dave! >>> >>> See attached files for make output in verbose mode and generated assembler code. >>> >>> Eugene. >>> ________________________________________ >>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>> Sent: Tuesday, November 20, 2012 3:18 PM >>> To: discuss(a)mpich.org >>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>> >>> It seems unlikely to me that the headers distributed in RHEL5/RHEL6 are incompatible with GCC being in C99 mode. Can you give me a little more information about what's failing? Perhaps run "make V=1 2>&1 | tee m.txt" and send m.txt as an attachment? >>> >>> -Dave >>> >>> On Nov 20, 2012, at 5:08 PM CST, Yauheni Zelenko wrote: >>> >>>> Hi, Dave! >>>> >>>> I think this is result of inlining in C99 mode. >>>> >>>> Eugene. >>>> ________________________________________ >>>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>>> Sent: Tuesday, November 20, 2012 3:06 PM >>>> To: discuss(a)mpich.org >>>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>>> >>>> I'm not sure I follow you on the fstat64/stat64 double-definition issue. Is this just some sort of bug in the RHEL6 headers? Is there something that we (MPICH) are doing incorrectly w.r.t. this? >>>> >>>> -Dave >>>> >>>> On Nov 14, 2012, at 5:39 PM CST, Yauheni Zelenko wrote: >>>> >>>>> Hi, Dave! >>>>> >>>>> Build failed on first compilation because fstat64 and stat64 defined twice. Likely because of these functions inlining in /usr/include/sys/stat.h. >>>>> >>>>> Also GCC 4.7.2 warnings on Red Hat Enterprise Linux 6: >>>>> >>>>> src/mpltrmem.c: In function 'MPL_trdump': >>>>> src/mpltrmem.c:536:14: warning: variable 'old_head' set but not used [-Wunused-but-set-variable] >>>>> src/mpi/coll/opminloc.c: In function 'MPIR_MINLOC': >>>>> src/mpi/coll/opminloc.c:85:24: warning: variable 'flen' set but not used [-Wunused-but-set-variable] >>>>> src/mpi/coll/opmaxloc.c: In function 'MPIR_MAXLOC': >>>>> src/mpi/coll/opmaxloc.c:86:24: warning: variable 'flen' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/ch3/src/ch3u_rma_sync.c: In function 'MPIDI_CH3I_Recv_rma_msg': >>>>> src/mpid/ch3/src/ch3u_rma_sync.c:1251:5: warning: 'mpiu_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpid/ch3/src/mpidi_pg.c: In function 'connToString': >>>>> src/mpid/ch3/src/mpidi_pg.c:972:5: warning: 'mpiu_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c: In function 'MPIDI_CH3I_Progress': >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:394:21: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c: In function 'MPID_nem_handle_pkt': >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:636:17: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:684:13: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c: In function 'alloc_sc_plfd_tbls': >>>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:183:5: warning: the comparison will always evaluate as 'true' for the address of 'MPID_nem_tcp_g_lstn_sc' will never be NULL [-Waddress] >>>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:184:5: warning: the comparison will always evaluate as 'true' for the address of 'MPID_nem_tcp_g_lstn_plfd' will never be NULL [-Waddress] >>>>> src/mpid/common/datatype/mpid_type_debug.c: In function 'MPIDI_Datatype_printf': >>>>> src/mpid/common/datatype/mpid_type_debug.c:238:59: warning: variable 'sticky_ub' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/common/datatype/mpid_type_debug.c:238:48: warning: variable 'sticky_lb' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/common/datatype/mpid_type_debug.c:238:44: warning: variable 'ub' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/common/datatype/mpid_type_debug.c:238:31: warning: variable 'true_ub' set but not used [-Wunused-but-set-variable] >>>>> src/mpid/common/datatype/mpid_type_debug.c:236:11: warning: variable 'string' set but not used [-Wunused-but-set-variable] >>>>> src/mpi/coll/iallgather.c: In function 'MPIR_Iallgather_bruck': >>>>> src/mpi/coll/iallgather.c:329:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallgather.c: In function 'MPIR_Iallgather_inter': >>>>> src/mpi/coll/iallgather.c:580:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallgatherv.c: In function 'MPIR_Iallgatherv_rec_dbl': >>>>> src/mpi/coll/iallgatherv.c:259:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallgatherv.c: In function 'MPIR_Iallgatherv_bruck': >>>>> src/mpi/coll/iallgatherv.c:398:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallreduce.c: In function 'MPIR_Iallreduce_redscat_allgather': >>>>> src/mpi/coll/iallreduce.c:282:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/iallreduce.c: In function 'MPIR_Iallreduce_rec_dbl': >>>>> src/mpi/coll/iallreduce.c:425:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/ired_scat_block.c: In function 'MPIR_Ireduce_scatter_block_inter': >>>>> src/mpi/coll/ired_scat_block.c:899:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> src/mpi/coll/ireduce.c: In function 'MPIR_Ireduce_SMP': >>>>> src/mpi/coll/ireduce.c:677:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>>> >>>>> Eugene. >>>>> ________________________________________ >>>>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>>>> Sent: Wednesday, November 14, 2012 2:46 PM >>>>> To: discuss(a)mpich.org >>>>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>>>> >>>>> This is because you have selected a bare "--enable-strict" option to configure, which defaults to c89. I'll see if there's a more pleasant way around this, but in the meantime is it acceptable for you to pass "--enable-strict=c99" instead? >>>>> >>>>> The problem occurs because your compiler still responds to the "long long" type but disables the "LLONG_MAX" constant when asked for c89 mode. >>>>> >>>>> -Dave >>>>> >>>>> On Nov 14, 2012, at 4:14 PM CST, Yauheni Zelenko wrote: >>>>> >>>>>> Hi! >>>>>> >>>>>> I'm trying to compile MPICH 3.0 rc1 on Red Hat Enterprise Linux 5 and compilation failed because of undefined LLONG_MAX. >>>>>> >>>>>> LLONG_MAX definition in /usr/include/limits.h is depend on C99 condition. -std=c89 is passed to GCC. >>>>>> >>>>>> My configure options: >>>>>> >>>>>> ./configure --prefix=${InstallDir} \ >>>>>> --with-pm=hydra --with-device=ch3:nemesis \ >>>>>> --disable-chekpointing \ >>>>>> --enable-strict --enable-fast=O3 \ >>>>>> --disable-f77 --disable-fc \ >>>>>> CC=/grid/common/pkgs/gcc/v4.4.5/bin/gcc CFLAGS="-m32 -fPIC" \ >>>>>> CPP=/grid/common/pkgs/gcc/v4.4.5/bin/cpp \ >>>>>> CXX=/grid/common/pkgs/gcc/v4.4.5/bin/g++ CXXFLAGS="-m32 -fPIC" \ >>>>>> CXXCPP=/grid/common/pkgs/gcc/v4.4.5/bin/cpp >>>>>> >>>>>> GCC 4.4.5 is also produce next warnings: >>>>>> >>>>>> mpi-io/write.c: In function 'MPIOI_File_write': >>>>>> mpi-io/write.c:126: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_all.c: In function 'MPIOI_File_write_all': >>>>>> mpi-io/write_all.c:109: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_allb.c: In function 'MPIOI_File_write_all_begin': >>>>>> mpi-io/write_allb.c:105: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_ord.c: In function 'PMPI_File_write_ordered': >>>>>> mpi-io/write_ord.c:98: warning: assignment discards qualifiers from pointer target type >>>>>> mpi-io/write_ord.c:100: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_ordb.c: In function 'PMPI_File_write_ordered_begin': >>>>>> mpi-io/write_ordb.c:104: warning: assignment discards qualifiers from pointer target type >>>>>> mpi-io/write_ordb.c:106: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/write_sh.c: In function 'PMPI_File_write_shared': >>>>>> mpi-io/write_sh.c:100: warning: assignment discards qualifiers from pointer target type >>>>>> mpi-io/write_sh.c:102: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>>> mpi-io/mpiu_external32.c: In function 'MPIU_write_external32_conversion_fn': >>>>>> mpi-io/mpiu_external32.c:24: warning: implicit declaration of function 'MPIR_Datatype_iscontig' >>>>>> mpi-io/mpiu_external32.c:24: warning: nested extern declaration of 'MPIR_Datatype_iscontig' >>>>>> mpi-io/mpiu_external32.c: In function 'MPIU_datatype_full_size': >>>>>> mpi-io/mpiu_external32.c:123: warning: unused variable 'extent' >>>>>> ./pm/pmiserv/pmip_cb.c: In function 'parse_exec_params': >>>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 1) >>>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 1) >>>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 2) >>>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 2) >>>>>> src/mpi/datatype/status_set_elements.c: In function 'PMPI_Status_set_elements': >>>>>> src/mpi/datatype/status_set_elements.c:54: warning: unused variable 'size' >>>>>> src/mpi/datatype/status_set_elements_x.c: In function 'MPIR_Status_set_elements_x_impl': >>>>>> src/mpi/datatype/status_set_elements_x.c:41: error: 'LLONG_MAX' undeclared (first use in this function) >>>>>> src/mpi/datatype/status_set_elements_x.c:41: error: (Each undeclared identifier is reported only once >>>>>> src/mpi/datatype/status_set_elements_x.c:41: error: for each function it appears in.) >>>>>> >>>>>> Eugene. >>>>>> _______________________________________________ >>>>>> discuss mailing list discuss(a)mpich.org >>>>>> To manage subscription options or unsubscribe: >>>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>>> >>>>> _______________________________________________ >>>>> discuss mailing list discuss(a)mpich.org >>>>> To manage subscription options or unsubscribe: >>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>>> _______________________________________________ >>>>> discuss mailing list discuss(a)mpich.org >>>>> To manage subscription options or unsubscribe: >>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> <make><close.s>_______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

using MPICH_FAILED_PROCESSES
by Ma, Zhaoming 27 Nov '12

27 Nov '12

I am trying to use the following to catch failed processes, MPI::COMM_WORLD.Get_attr(MPICH_ATTR_FAILED_PROCESSES, void*) I am using MPICH2 1.4 and g++. Someone posted a C program that does this successfully. The link is http://hi.baidu.com/ejoywx/item/74233ccb9dd20815515058ae. However, I am having trouble making my C++ testing program (attached) working. The code compiled ok but produces the following runtime error, terminate called after throwing an instance of 'MPI::Exception' APPLICATION TERMINATED WITH THE EXIT STRING: Aborted (signal 6) If I comment out the line "MPI::COMM_WORLD.Get_attr(MPICH_ATTR_FAILED_PROCESSES, void*)" or put it in a try and catch block, the test program runs fine. Thank you for your help. Zhaoming

1 0