[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