Sorry for the delay; this past weekend was a holiday in the US. I'm just now
catching up on the backlog.
Have you edited pml_ob1_comm.c? For me, line 56 (on the trunk) is:
OBJ_CONSTRUCT(&comm->matching_lock, opal_mutex_t);
But clearly you seem to be executing the line above that:
OBJ
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
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
Do u know which object it is that is being constructed? When you compile with
debugging enabled, theres strings in the object struct that identify te file
and line where the obj was created.
Sent from my phone. No type good.
On Jun 29, 2011, at 8:48 AM, "Xin He" wrote:
> Hi,
>
> As I adva
