Skip to content
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

Using std::default_delete<MpiComm> is undefined behaviour #585

Open
dmcdougall opened this issue May 25, 2017 · 2 comments
Open

Using std::default_delete<MpiComm> is undefined behaviour #585

dmcdougall opened this issue May 25, 2017 · 2 comments
Labels
Milestone

Comments

@dmcdougall
Copy link
Member

Example

@dmcdougall dmcdougall added the bug label May 25, 2017
@dmcdougall dmcdougall added this to the v0.57.1 milestone May 25, 2017
@dmcdougall
Copy link
Member Author

dmcdougall commented May 26, 2017

Actually, no it isn't, because MpiComm is a QUESO object, not an MPI object.

That said, we're committing other atrocities:

  1. We straight up copy communicators, including context, rather than calling MPI_Comm_dup;
  2. We don't call MPI_Comm_free on communicators in MpiComm::~MpiComm;
  3. If we did do 2., then upon reaching the end of whatever scope contains FullEnvironment, presumably MPI_Finalize() would have already been called and then after that we start calling MPI_Comm_free. MPI would error;
  4. Fixing 3. by doing 2. means users need to scope all of QUESO's objects which is a backwards-incompatible change;
  5. We could call MPI_Finalized() to test if MPI_Finalize() was called and if it was, don't call MPI_Comm_free. This introduces memory leaks;

@dmcdougall dmcdougall modified the milestones: v0.58.0, v0.57.1 May 26, 2017
@dmcdougall
Copy link
Member Author

Related issue: #587.

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

No branches or pull requests

1 participant