opal/datatype: fix opal_convertor_raw()

[ggouaillardet]

No description provided.

[ggouaillardet]

@bosilca can you please review this ?

Refs. #6285

[ggouaillardet]

@edgargabriel FYI, this fixes the hdf5 data corruption reported in #6285

[edgargabriel]

@ggouaillardet thank you, I will test it later today. I can however confirm that it is inline with my analysis over the weekend, that the values that ompio received from the convertor_raw function looked incorrect.

[hppritcha]

bot:lanl:retest

[ax3l]

@ggouaillardet @edgargabriel thank you a lot for finding the root source of this and the PR!
Just to understand the implications for users, does this fix only affect I/O or is opal_convertor_raw used somewhere else as well which might affect other components?

[edgargabriel]

@ax3l if I remember correctly, the convertor_raw function is also used in the osc/rdma component as well

[hppritcha]

bot:ompi:retest

[hjelmn]

Looks fine to me. Let's go ahead and bring this into master. Please PR to the affected branches and tag @bosilca to review.

[bosilca]

For the sake of completeness, the solution proposed here is not really working on all cases. A better approach has been proposed in #6326 .

[hjelmn]

@bosilca Great. Will test with that. Trying to get ARMCI fully tested with osc/rdma and this helped it pass.

[ggouaillardet]

thanks @bosilca, I will test the new PR

@hjelmn FWIW, I do not think the derived datatypes used by ARMCI are complex enough (read the description exceeds OMPI_OSC_RDMA_DECODE_MAX = 64 elements) to be impacted by this fix.

[bosilca]

The underlying issue can be replicated with a simple vector, as long as the iov_count is smaller than the count of the vector. Moreover, now that I understood the issue I think we might have the same type of problems in the pack/unpack, which is what #6172 is trying to address. Will try to take a look tomorrow.