On Thu, Mar 21, 2013 at 7:00 PM, Mark F. Adams <[email protected]>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 <[email protected]> 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 <[email protected]>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