This repository was archived by the owner on Sep 30, 2022. It is now read-only.
v2.0.1: odls_default: do not opal_output() while creating a process! #1190
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is verbotten to use opal_output() after the fork() but before the
exec()! It results in all manner of undefined behavior. For example,
on some OS X systems, if you run a trivial "hello world" MPI program
with a high level of ODLS verbosity:
You will see a bunch of output from the mpirun ODLS base, but then it
may hang in odls_default_module.c:do_child() -- after the fork() but
before the exec() -- while trying to opal_output() some debugging
statements.
The solution is to remove these extraneous opal_output() statements.
Indeed, the ODLS base is already outputting the same information that
these opal_output() statements are trying to emit, anyway.
Signed-off-by: Jeff Squyres jsquyres@cisco.com
(cherry picked from commit open-mpi/ompi@dd9a819)
@hppritcha This is safe for v2.0.1 because a) it only happens on some systems, and b) it's fairly esoteric to run with
odls_base_verbose>10 (which is what causes the problem).@rhc54 Please review for v2.0.1.