I've tried to use valgrind in order to debug my system.
But the only errors i get are from mpi,
then shall i ask you if there're some particular specifications to give in
order to let valgrind signal the errors ?
I'm still blocked on the same error :
In some runs (not all) , one or more processes keeps blocked in probing, or in
sending .... i though it was a buffer allocation error but it seem that it's
not ...
If someone could ever help .....
Le Samedi 17 Décembre 2005 18:44, mouraud_anthony a écrit :
> well, i'll try to run it through some memory-checking after having had a
> look at the FAQ on that topic.
>
> But i can precise my problem so that you'll perhaps have a easier solution
> to this :
> i know the non-blocking behavior of Iprobe and that's why i use it. In the
> case i told you, the process never returns from iprobe or the process
> catches a sigsegv in iprobe, which is not the case in some other messages
> exanges, i have to kill the execution ... I must precise i'm running a
> multithreaded mpi progam, in lam 7-1-1, but only one process in each node
> does send and receive messages ...
> i indeed think it's a memory problem ... but don't know which one really
> ... so perhaps the memory checker is the best way to answer my question ...
>
> thank you for your helping response, i'll tell you about the evolution of
> my problem :-)
> see you
>
> Le Vendredi 16 Décembre 2005 15:47, Jeff Squyres a écrit :
> > On Dec 15, 2005, at 10:30 AM, mouraud_anthony wrote:
> > > i'm blocking for a while on an mpi error inside iprobe.
> > > well, the node probing gets a segfault, and the lam stack indicates
> > > it happens inside iprobe.
> >
> > I'm not entirely sure what you mean -- how are you blocking in an
> > MPI_Iprobe? By definition, MPI_Iprobe is non-blocking, and will
> > return immediately. Do you mean that you are looping over MPI_Iprobe
> > until flag returns 1?
> >
> > You might want to run your code through a memory-checking debugger
> > (see the LAM FAQ for some important notes about this) to see if there
> > are any non-obvious errors occurring. That is almost always the
> > first step when tracking down problems like this.
> >
> > --
> > {+} Jeff Squyres
> > {+} The Open MPI Project
> > {+} http://www.open-mpi.org/
> >
> >
> >
> > _______________________________________________
> > This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
|
