[mpich-discuss] -mpe=mpitrace not producing any output

[François PELLEGRINI]

mpich-discuss-request at mcs.anl.gov wrote:
> Message: 2
> Date: Mon, 5 Jan 2009 13:00:09 -0600 (CST)
> From: Anthony Chan <chan at mcs.anl.gov>

> ----- "Fran?ois PELLEGRINI" <francois.pellegrini at labri.fr> wrote:
>> First, I have trouble using the "mpitrace" feature of MPE.
>> I compile all of my source code with "mpicc -mpe=mpitrace",
>> and link the objects with "-ltmpe", but absolutely no output
>> is produced when I run the compiled program. This both happens
>> with the official 1.0.8 and r3717 packages. What did I do
>> wrong ?
> 
> just tried -mpe=mpitrace with cpi.c in 
> <mpich2_108_install_dir>/share/examples_logging,
> I see trace output appears on my terminal.
> What program are you trying this ?

Scotch, the code I develop. It is ~ 100 klines, so difficult
to reduce it to a small test case.  ;-)

Scotch has many files. Can it be that the mpitrace flag
is lost for pure ld operation of mpicc, so that it works
for the direct compilation of your mono-file example but
fails for multi-file examples ? I guess so.

Indeed, as James S Perrin (<james.s.perrin at manchester.ac.uk>)
reported in another e-mail, the only output I get is a bunch
of MPI_Finalize reports, which only concern my main object
file.

> If the program is small, can you send me the
> code so I can check/confirm if MPE has any bug ?
> 
> In terms of Valgrind, did you configure mpich2 with --enable-g=meminit
> which reduces some valgrind warnings...?  See "configure --help"
> for more info.

Yes, of course.

Dave Goodell wrote:
> Can you boil this down to a small test program that we can use to
> reproduce this?

Nope. Scotch is heavy : can use multiple threads (disabled here not
to add problems), uses sub-communicators created by MPI_Comm_split,
does collective communications and immediate sends-recvs on them,
well, hard to reduce to a test case without losing the semantics
and trace of the MPI calls.

>  It's difficult to figure out what's happening without a
> test program.  A small test program should also help you rule out user
> error such as mismatched send/recv calls.

I know.

> As far as the valgrind output is concerned, make sure that you are
> configuring mpich2 with --enable-g=meminit,dbg (or some superset,
> including --enable-g=all).  Adding "mem" and "handle" to the --enable-g
> list can also help find certain problems.

I did it. The string I use is :

./configure --prefix=$HOME/mpich/ CPPFLAGS='-I/usr/include/valgrind'
--enable-error-checking=all --enable-error-messages=all --enable-g=all
--enable-fast=defopt --enable-debuginfo --enable-mpe --enable-threads=multiple
--with-thread-package=posix --disable-f77

I see nothing wrong with it. I compile each of my library .c files and my
main executables with -mpe=mpitrace, and link the whole with -ltmpe .

A+,


					f.p.