Check the runtime version of PMIx #2
Conversation
|
Hello! The Git Commit Checker CI bot found a few problems with this PR: 0fa074e: Check the runtime version of PMIx
Please fix these problems and, if necessary, force-push new commits back up to the PR branch. Thanks! |
hppritcha
force-pushed
the
upstream_pr_1982
branch
from
0fa074e
to
0ec08e3
Compare
|
Hello! The Git Commit Checker CI bot found a few problems with this PR: 0ec08e3: Check the runtime version of PMIx
Please fix these problems and, if necessary, force-push new commits back up to the PR branch. Thanks! |
|
You probably need to add 2ac45f3 to disable the MacOS builds as Homebrew has broken them. |
|
If PR openpmix#1987 is accepted upstream, it fixes the MacOS github action tests. We could pull the commit from that PR here. |
@hppritcha The upstream PR was accepted: you can cherry-pick commit 4a682ef670d2582ffda2e990428446138f7c10d7 |
hppritcha
force-pushed
the
upstream_pr_1982
branch
from
0ec08e3
to
5033ba0
Compare
|
Hello! The Git Commit Checker CI bot found a few problems with this PR: 5033ba0: Check the runtime version of PMIx
Please fix these problems and, if necessary, force-push new commits back up to the PR branch. Thanks! |
It has been reported (and confirmed) that building against one version of PMIx and then running with another version will cause PRRTE to segfault. This isn't a universal rule. For example, one can switch v5.0 and master without a problem. However, switching v5.0 and v4.2 is a definite segfault. The root cause of the problem is a change in the layout of the base pmix_object_t definition. This renders all PMIx objects binary incompatible when crossing between the v5 and v4 (and below) series. Changing the v5 definition back to match v4 is an overly complex task. The changes were required to accommodate the new shared memory support that was introduced in v5. So instead, we check the runtime version of PMIx against the build version. If the runtime version is incompatible with the build version, then we print an explanatory error message and error out. Signed-off-by: Ralph Castain <rhc@pmix.org> bot:notacherrypick dd Signed-off-by: Ralph Castain <rhc@pmix.org>
hppritcha
force-pushed
the
upstream_pr_1982
branch
from
5033ba0
to
1315332
Compare
|
@jsquyres ready for a "re" review |
It has been reported (and confirmed) that building against one version of PMIx and then running with another version will cause PRRTE to segfault. This isn't a universal rule. For example, one can switch v5.0 and master without a problem. However, switching v5.0 and v4.2 is a definite segfault.
The root cause of the problem is a change in the layout of the base pmix_object_t definition. This renders all PMIx objects binary incompatible when crossing between the v5 and v4 (and below) series.
Changing the v5 definition back to match v4 is an
overly complex task. The changes were required to
accommodate the new shared memory support that
was introduced in v5.
So instead, we check the runtime version of PMIx against the build version. If the runtime version is incompatible with the build version, then we print an explanatory error message and error out.
Signed-off-by: Ralph Castain rhc@pmix.org
dd
Signed-off-by: Ralph Castain rhc@pmix.org
(cherry picked from commit d02ad07)