r32248 should be the fix for this issue. I was overly optimistic about the
cleanup of the classes. It turns out this is not possible without deep
rearrangement of the class infrastructure. More info on the commit log.
Sorry for the mess,
George.
On Tue, Jul 15, 2014 at 11:38 AM, George Bosilc
I'm also looking into it.
George.
On Tue, Jul 15, 2014 at 10:50 AM, Nathan Hjelm wrote:
> On Tue, Jul 15, 2014 at 11:40:38PM +0900, Gilles GOUAILLARDET wrote:
> >r32236 is a suspect
> >
> >i am afk
> >
> >I just read the code and a class is initialized with
> opal_class_initiali
On Tue, Jul 15, 2014 at 11:40:38PM +0900, Gilles GOUAILLARDET wrote:
>r32236 is a suspect
>
>i am afk
>
>I just read the code and a class is initialized with opal_class_initialize
>the first time an object is instantiated with OBJ_NEW
>
>I would simply revert r32236 or update
r32236 is a suspect
i am afk
I just read the code and a class is initialized with opal_class_initialize the
first time an object is instantiated with OBJ_NEW
I would simply revert r32236 or update opal_class_finalize and
free(cls->cls_construct_array); only if cls->cls_construct_array is not N
Hi folks
The changes to opal_class_finalize are generating 100% segfaults on the trunk:
175 free(cls->cls_construct_array);
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.132.el6_5.2.x86_64 libgcc-4.4.7-4.el6.x86_64
numactl-2.0.7-8.el6.x86_64
(gdb) where
#0 0x
