Hi, here is the result:
ehhexxn@oak:~/git/test$ mpirun -n 2 -mca btl tipc,self valgrind
./hello_c > 11.out
==30850== Memcheck, a memory error detector
==30850== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==30850== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h fo
Keep in mind, too, that opal_object is the "base" object -- put in C++ terms,
it's the abstract class that all other classes are made of. So it's rare that
we could create a opal_object by itself. opal_objects are usually created as
part of some other, higher-level object.
What's the full cal
Hi,
I ran the program with valgrind, and it showed almost the same error. It
appeared that the segmentation fault happened during
the initiation of an opal_object. That's why it puzzled me.
/Xin
On 07/04/2011 01:40 PM, Jeff Squyres wrote:
Ah -- so this is in the template code. I suspect t
On Jul 3, 2011, at 8:40 PM, Kawashima wrote:
>> Does your llp sed path order MPI matching ordering? Eg if some prior isend
>> is already queued, could the llp send overtake it?
>
> Yes, LLP send may overtake queued isend.
> But we use correct PML send_sequence. So the LLP message is queued as
>
Ah -- so this is in the template code. I suspect this code might have bit
rotted a bit. :-\
If you run this through valgrind, does anything obvious show up? I ask because
this kind of error is typically a symptom of the real error. I.e., the real
error was some kind of memory corruption tha
Yes, it is a opal_object.
And this error seems to be caused by these code:
void mca_btl_template_proc_construct(mca_btl_template_proc_t*
template_proc){
...
.
/* add to list of all proc instance */
OPAL_THREAD_LOCK(&mca_btl_template_component.template_lock);
opa
