[Resending with Charles on the CC line, not sure how he got dropped...] On Jan 11, 2012, at 9:46 AM, Dave Goodell wrote:
This change shouldn't be necessary, as far as I can tell at least. Yes, those fields do alias each other, which is technically a violation of C's aliasing rules. But in practice I doubt this is the issue that you are running into.
The object is never simultaneously referred to via MPIU_Handle_common and MPID_Datatype. The "common" type is used inside the allocator when the object is unallocated, and the "Datatype" type is used outside of the allocator when the object is in the allocated state.
Can you explain more precisely where the above assumption is violated? Is the datatype object being used before/after it has been allocated?
-Dave
On Jan 4, 2012, at 1:11 PM, Charles J Archer wrote:
That was my first thought as well, and thought this should be the correct approach.
We tried the experiment to move it there and hit additional compilation errors. Some objects have this field, others do not, leading to some inconsistency.
It certainly would be less error prone to put it in the header, rather than assuming all objects derived from this will have a next field.
Thanks,
-C
Charles J Archer Parallel Environment MPI Team Lead LAPI, Communication Protocols and Tools BlueGene DCMF and Hybrid DaCS SDK Advanced Clustering Technology Team (ACTT) Dept X2ZA, Bldg 030-2, IBM Rochester MN 55901 [email protected] (507) 253-0346 TL 8-553-0346 Fax (507) 253-2870
<graycol.gif>Darius Buntinas ---01/04/2012 02:46:48 PM---It looks to me that the next field should be moved into the MPIU_OBJECT_HEADER macro. Does anyone (
<ecblank.gif> From: <ecblank.gif> Darius Buntinas <[email protected]> <ecblank.gif> To: <ecblank.gif> [email protected], <ecblank.gif> Cc: <ecblank.gif> Brian Smith/Rochester/IBM@IBMUS, Charles J Archer/Rochester/ IBM@IBMUS, Haizhu Liu/Poughkeepsie/IBM@IBMUS <ecblank.gif> Date: <ecblank.gif> 01/04/2012 02:46 PM <ecblank.gif> Subject: <ecblank.gif> Re: [mpich2-maint] MPIU_Handle_common casting to MPID_Datatype
It looks to me that the next field should be moved into the MPIU_OBJECT_HEADER macro. Does anyone (with fresher knowledge on object allocation than me) know if this isn't a good idea, or why it wasn't done?
Thanks, -d
On Jan 3, 2012, at 8:28 PM, Haizhu Liu wrote:
In file mpich2/src/mpi/datatype/typeutil.c function MPIR_Datatype_init(), the code calls
ptr = (MPID_Datatype *)MPIU_Handle_obj_alloc_unsafe( &MPID_Datatype_mem );
Function MPIU_Handle_obj_alloc_unsafe returns the address of data of type MPIU_Handle_common. The casting has problem, because later it interprets the second element "void *" in MPIU_Handle_common as the second element "int size" in MPID_Datatype, which is what I saw with mpich test bucket io/rdwrord test case where it tries to call PAMI_Memregion_create() on a huge size of buffer.
typedef struct MPIU_Handle_common { MPIU_OBJECT_HEADER; void *next; /* Free handles use this field to point to the next free object */ } MPIU_Handle_common;
typedef struct MPID_Datatype { /* handle and ref_count are filled in by MPIU_Handle_obj_alloc() */ MPIU_OBJECT_HEADER; /* adds handle and ref_count fields */
/* basic parameters for datatype, accessible via MPI calls */ int size; /* adding void *next before this element fixes the problem */ MPI_Aint extent, ub, lb, true_ub, true_lb;
/* chars affecting subsequent datatype processing and creation */ int alignsize, has_sticky_ub, has_sticky_lb; int is_permanent; /* non-zero if datatype is a predefined type */ int is_committed;
... }
Adding void *next as the second element in MPID_Datatype() fixed the problem. Is the fix okay?
Thanks, Haizhu
Communication Protocols Advance Clustering Technology Team (ACTT) IBM System and Technology Group Poughkeepsie, NY 12601 Phone : (845)-433-5857 (T/L: 293)_______________________________________________ mpich2-maint mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/mpich2-maint