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

[burlen]

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