[mvapich-discuss] osu_cas_latency in OMB v.5.4.2 corrupts memory

[Sourav Chakraborty]

Hi John,

Thanks for reporting the issue. The attached patch uses posix_memalign and
should fix it. This fix will be included as part of the next OMB release.

Thanks,
Sourav


On Thu, Jul 12, 2018 at 7:10 PM Byrne, John (Labs) <john.l.byrne at hpe.com>
wrote:

> The immediate problem appears that the xxx_original arrays sizes in
> osu_cas_latency.c are MYBUFSIZE  (MAX_MESSAGE_SIZE). So, with the default
> opts.max_message_size of MAX_MESSAGE_SIZE (process_options() overwrites the
> value set at the beginning of main()), when allocate_atomic_memory() aligns
> the buffer pointer to page_size there is no padding available in the array
> and then the following memset(,,MAX_MESSAGE_SIZE) goes past the end of the
> buffer. The trivial overkill fix is to declare the arrays with size
> ONEBUFSIZE; however, I really don’t understand why the
> allocate_memory_one_sided() and alloc_atomic_memory() routines don’t simply
> allocate memory using posix_memalign() in the non-device-memory case rather
> than aligning the passed-in original buffer and using that: it just seems
> like asking for trouble.
>
>
>
> John Byrne
>
>
> _______________________________________________
> mvapich-discuss mailing list
> mvapich-discuss at cse.ohio-state.edu
> http://mailman.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/attachments/20180713/b496cc5d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omb_mem_align.patch
Type: application/octet-stream
Size: 35345 bytes
Desc: not available
URL: <http://mailman.cse.ohio-state.edu/pipermail/mvapich-discuss/attachments/20180713/b496cc5d/attachment-0001.obj>