Hi Jim, That's what my vague recollection was, however valgrind is reporting that the object was free'd when I called type free, and MPI later crashes when starts using that data. In the report bellow vtkPixelTransfer::Execute is where I call irecv and then type free. I'm wondering if there a way to access the reference count? I'd like to verify that it's not 0 after I call type free. Burlen ==9094== Invalid read of size 4 ==9094== at 0x1A0FF16C: MPID_Segment_manipulate (segment.c:429) ==9094== by 0x1A108280: MPID_Segment_pack (segment_packunpack.c:63) ==9094== by 0x1A0D1A8B: MPIDI_CH3I_Shm_send_progress (mpid_nem_inline.h:458) ==9094== by 0x1A0D42F1: MPIDI_CH3I_Progress (ch3_progress.c:438) ==9094== by 0x1A1DE5BB: PMPI_Waitany (waitany.c:198) ==9094== by 0x103D0692: vtkSurfaceLICComposite::Gather(void*, int, int, vtkTextureObject*&) (vtkSurfaceLICComposite.cxx:1511) ==9094== by 0x103F0673: vtkSurfaceLICPainter::RenderInternal(vtkRenderer*, vtkActor*, unsigned long, bool) (vtkSurfaceLICPainter.cxx:2944) ==9094== by 0x156D9A1E: vtkPainter::Render(vtkRenderer*, vtkActor*, unsigned long, bool) (vtkPainter.cxx:218) ==9094== by 0x156D9A95: vtkPainter::RenderInternal(vtkRenderer*, vtkActor*, unsigned long, bool) (vtkPainter.cxx:228) ==9094== by 0x125D0D09: vtkOpenGLClipPlanesPainter::RenderInternal(vtkRenderer*, vtkActor*, unsigned long, bool) (vtkOpenGLClipPlanesPainter.cxx:101) ==9094== by 0x156D9A1E: vtkPainter::Render(vtkRenderer*, vtkActor*, unsigned long, bool) (vtkPainter.cxx:218) ==9094== by 0x156D9A95: vtkPainter::RenderInternal(vtkRenderer*, vtkActor*, unsigned long, bool) (vtkPainter.cxx:228) ==9094== Address 0x284dcc18 is 152 bytes inside a block of size 384 free'd ==9094== at 0x4C2B7BE: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9094== by 0x20E8D1C7: MPL_trfree (in /work/apps/mpich-3.0.3-D/lib/libmpl.so.1.0.0) ==9094== by 0x1A0689DC: MPIU_trfree (trmem.c:37) ==9094== by 0x1A0F984E: MPID_Dataloop_free (dataloop.c:71) ==9094== by 0x1A109E9A: MPID_Datatype_free (mpid_datatype_free.c:51) ==9094== by 0x1A19B577: MPIR_Type_free_impl (type_free.c:35) ==9094== by 0x1A19B9BC: PMPI_Type_free (type_free.c:138) ==9094== by 0x10389EB4: int vtkPixelTransfer::Execute<float, float>(int, int, int, float*, float*, std::vector<int, std::allocator<int> >&, int) (vtkPixelTransfer.h:607) ==9094== by 0x10382D3F: int vtkPixelTransfer::Execute<float>(int, int, int, float*, int, void*, std::vector<int, std::allocator<int> >&, int) (vtkPixelTransfer.h:454) ==9094== by 0x10382135: vtkPixelTransfer::Execute(int, int, int, int, void*, int, void*, std::vector<int, std::allocator<int> >&, int) (vtkPixelTransfer.cxx:33) ==9094== by 0x103CFD08: vtkSurfaceLICComposite::Gather(void*, int, int, vtkTextureObject*&) (vtkSurfaceLICComposite.cxx:1396) ==9094== by 0x103F0673: vtkSurfaceLICPainter::RenderInternal(vtkRenderer*, vtkActor*, unsigned long, bool) (vtkSurfaceLICPainter.cxx:2944) On 04/22/2013 02:40 PM, Jim Dinan wrote:
Hi Burlen,
You can free the datatype as soon as you are finished using it. MPI will internally maintain a reference to the datatype so that it is not actually freed until both the MPI library and the application code are finished using it.
~Jim.
On 4/22/13 4:29 PM, burlen wrote:
Can anyone clarify about using subarray datatype with irecv, When is ok to free the subarray data type? Can I do so immediately after calling irecv? or must I wait until the recv really finishes? I didn't see any specific language about this in the documentation , but I'm experiencing segfaults when MPI accesses previously free'd memory in the datatype.
Thanks Burlen _______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss
discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss