Skip to content

v4.0.x: apply romio314 patch to romio321 #5493

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

markalle
Copy link
Contributor

@markalle markalle commented Jul 27, 2018

When romio314 was first pulled in an extra patch was applied to it, see commit
92f6c7c. Most of that patch is already present
in vanilla romio321, but the fix for MPIO_DATATYPE_ISCOMMITTED() isn't.

If that macro doesn't set err_ then some paths end up with a variable being used
uninitialized. In particular you can trace through romio321/romio/mpi-io/read.c
to see what happens with error_code. It's an uninitialized stack variable that goes
through three MPIO_CHECK_* macros none of which set it. The macros consistently set
error_code to a failure if they see something wrong, but they don't consistently
set it to success when things are fine.

And then in the last macro MPIO_CHECK_DATATYPE it tries to look at the value
of error_code that was never set.

fixes 5489

When romio314 was first pulled in an extra patch was applied to it, see commit
92f6c7c. Most of that patch is already present
in vanilla romio321, but the fix for MPIO_DATATYPE_ISCOMMITTED() isn't.

If that macro doesn't set err_ then some paths end up with a variable being used
uninitialized. In particular you can trace through romio321/romio/mpi-io/read.c
to see what happens with error_code. It's an uninitialized stack variable that goes
through three MPIO_CHECK_* macros none of which set it. The macros consistently set
error_code to a failure if they see something wrong, but they don't consistently
set it to success when things are fine.

And then in the last macro MPIO_CHECK_DATATYPE it tries to look at the value
of error_code that was never set.

Signed-off-by: Mark Allen <[email protected]>
@jsquyres
Copy link
Member

Is this a cherry-pick from master?

@hppritcha
Copy link
Member

probably @markalle @gpaulsen we need indication of the sha of the commit into master, best if its in the commit message. you can pick this up automatically by using

git cherry-pick -x sha_of_commit_on_master

@jsquyres jsquyres changed the title apply romio314 patch to romio321 v4.0.x: apply romio314 patch to romio321 Jul 30, 2018
@jsquyres
Copy link
Member

No, this does not look like a cherry-pick from master -- it looks like #5494 is the PR to master.

Please merge #5494 first, and then cherry pick that to the release branch (so we can more easily track what has migrated from master to the release branch(es)).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants