[petsc-dev] Errors in ThreadComm stuff
Jed Brown
jedbrown at mcs.anl.gov
Thu Mar 21 19:06:47 CDT 2013
On Thu, Mar 21, 2013 at 7:00 PM, Mark F. Adams <mark.adams at columbia.edu>wrote:
> No, not intentionally, we don't touch threads.
>
I'm not sure, maybe funny business with thread-local storage. Based on the
stack trace above and the intent of this code, you can apply this for now.
diff --git i/src/sys/objects/tagm.c w/src/sys/objects/tagm.c
index 46e32c1..cc399ab 100644
--- i/src/sys/objects/tagm.c
+++ w/src/sys/objects/tagm.c
@@ -198,9 +198,7 @@ PetscErrorCode PetscCommDuplicate(MPI_Comm
comm_in,MPI_Comm *comm_out,PetscMPII
ierr = PetscCommGetThreadComm(*comm_out,&tcomm);CHKERRQ(ierr);
ierr = PetscThreadCommAttach(*comm_out,tcomm);CHKERRQ(ierr);
}
- /* Only the main thread updates counter->refcount */
- ierr = PetscThreadCommGetRank(tcomm,&trank);CHKERRQ(ierr);
- if (!trank) counter->refcount++; /* number of references to this comm */
+ counter->refcount++; /* number of references to this comm */
PetscFunctionReturn(0);
}
>
> On Mar 21, 2013, at 7:45 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> Did you enable threadcomm? I better finish this work I started and get my
> branch out there...
>
>
> On Thu, Mar 21, 2013 at 6:42 PM, Mark F. Adams <mark.adams at columbia.edu>wrote:
>
>> I'm getting segv in at the end of runs on the Cray XC30. in optimized
>> builds it segv with a stack like
>>
>> PetscFinalize
>> PetscViewerASCIIGetStdout
>> PetscCommDuplicate
>> PetscThreadCommGetRank
>>
>> In debug builds it does not segv but there are a bunch of un freeded
>> memory in ThreadComm stuff.
>>
>> Mark
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130321/30216aa5/attachment.html>
More information about the petsc-dev
mailing list