[mpich-discuss] non-blocking communication and subarray data type

[Dave Goodell]

Configure your MPICH with "--enable-g" and you should get some error checks to help with this.  If you point it at your valgrind headers then you might get even more useful output from Valgrind.  Something like "--with-valgrind=/Users/goodell/prefix/include" at configure time.

Based on the stack trace you posted, MPI certainly thinks that the refcount has dropped to 0.

-Dave

On Apr 22, 2013, at 6:06 PM CDT, burlen <burlen.loring at gmail.com> wrote:

> 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     discuss at mpich.org
>>> To manage subscription options or unsubscribe:
>>> https://lists.mpich.org/mailman/listinfo/discuss
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
> 
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss