[mpich-discuss] Bug reporting for some mpi/rma tests
Min Si
msi at anl.gov
Wed Jul 20 10:37:31 CDT 2016
Hi Clément,
Please use the test suite in the latest release, so you will not get
trouble with some bugs that we have already fixed.
Min
On 7/20/16 4:44 AM, Clément Foyer wrote:
> Hi Min,
>
> Although it may have been fixed in later version (as I am currently
> using test suite from mpich 3.1), the window creation (l.125) is
> stated as follow :
> MPI_Win_create( rmabuffer, bufsize, sizeof(int),
> MPI_INFO_NULL, MPI_COMM_WORLD, &win );
> with bufsize being equal to RMA_SIZE (2048) on master's side, and 0 on
> partner side. However, the bufsize argument is the size of the window
> in bytes, not in "displacement_unit" (here being sizeof(int) ). so the
> range is int[157: 157+512], but the window is defined with a range
> int[0: RMA_SIZE / sizeof(int)], creating an overflow.
>
> Clément FOYER
>
> Message: 1
> Date: Tue, 12 Jul 2016 09:46:59 -0500
> From: Min Si <msi at anl.gov <mailto:msi at anl.gov>>
> To: <discuss at mpich.org <mailto:discuss at mpich.org>>
> Subject: Re: [mpich-discuss] Bug reporting for some mpi/rma tests
> Message-ID: <fb8a89ae-ca43-317f-74c4-6ec2c49b8c4e at anl.gov
> <mailto:fb8a89ae-ca43-317f-74c4-6ec2c49b8c4e at anl.gov>>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Hi C. FOYER,
>
> Thanks for reporting bugs to us.
>
> However, the places in test rma/lockcontention3.c are correct.
> The buffers' size is RMA_SIZE (2048) count of int. In case 9, 10,
> 11 the
> operations' size is longcount(512) count of int, and the largest
> target
> displacement is OFFSET_3(157), which means the window buffer is
> accessed
> in range int[157: 157+512]. Thus no overflows.
>
> In rma/manyrma3.c, as you reported, we missed verification and winbuf
> initialization. We will fix it.
>
> Min
>
> On 7/12/16 3:08 AM, Cl?ment Foyer wrote:
> > Hi everyone,
> >
> > I think I may have found some bugs in mpich tests for RMA
> operations.
> >
> > First, in rma/lockcontention3.c.
> > When calling RMA operations, the different offsets are not taken in
> > account on the origin_count and target_count parameters. As the
> > buffers are the same sizes, when the count arguments are equal to
> > "longcount" (such as in the tests cases 9, 10 and 11), it either
> > overflows when the operation is actually done, or, as it should
> > preferably be done, it fails with the returns of the
> MPI_ERR_RMA_RANGE
> > error code.
> > Also, on the check function, there are some array overflows, as the
> > loops go from 0 to longcount-1, and the array is accessed with the
> > OFFSET (buf[OFFSET_1+j]).
> > The easiest solution would be to set bufsize (l.111) and getbufsize
> > (l.118) to RMA_SIZE+OFFSET_3 (OFFSET_3 being the bigger one), and
> > maybe allocate change l.123 to srcbuf = malloc((RMA_SIZE +
> > OFFSET_3)*sizeof(*srcbuf));
> > Also, the window is defined with the bufsize as size, which should
> > mean that the window is bufsize bytes long. But as it is an array of
> > int's, it would rather be bufsize*sizeof(int) long. There might be a
> > problem there as well, given the fact that the displacement unit
> given
> > is actually "sizeof(int)".
> >
> > rma/manyrma3.c
> > No verification is done. Just accumulate, and then we assume the
> > result is correct. Also, winbuf is not initialized.
> >
> > Sincerely yours,
> >
> > C. FOYER
>
>
>
> _______________________________________________
> discuss mailing list discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20160720/e1fefcbb/attachment.html>
-------------- next part --------------
_______________________________________________
discuss mailing list discuss at mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss
More information about the discuss
mailing list