Homebrew-core: Bottled MPICH segfaults

[mrzv]

The following example works fine on every MPI implementation I've tried, including brew install --HEAD mpich, but when compiled and run with the bottled MPICH (3.2_1), it segfaults.

// test-mpi.c

#include <mpi.h>

int main(int argc, char** argv)
{
    MPI_Init(&argc, &argv);

    MPI_Comm world = MPI_COMM_WORLD;

    int rank;
    MPI_Comm_rank(world, &rank);

    MPI_Comm local;
    MPI_Comm_split(world, rank, 0, &local);

    MPI_Finalize();
}

To compile and run:

mpicc test-mpi.c -o test-mpi
mpirun -n 2 ./test-mpi

[MikeMcQuaid]

Sorry but you have not followed the requested steps on the Troubleshooting page

Please follow (all of) these steps and post the information here so we can help you with your problem.

Thanks!

[mrzv]

The gist-logs are here https://gist.github.com/mrzv/dea48c710ff121fe0e9a2c0ffb6d5e0f

The doctor warnings are clearly unrelated.

[ilovezfs]

This is reproducible, and, as @mrzv said, a HEAD build works fine. However, simply rebuilding the bottle doesn't help. Of course, not terribly surprisingly a build of the tag with gcc is fine and doesn't segfault.

[mrzv]

@ilovezfs I have a tangentially related question. Is there a way for me to build 3.2 from source without uninstalling HEAD, only unlinking it? It used to be possible to say something like brew install --build-from-source [email protected]_1 (I may be messing it up), but that doesn't seem to work anymore. Do I have to uninstall HEAD first? I want to test if it's an actual bug in MPICH 3.2, and I need to report it upstream.

[ilovezfs]

@mrzv from IRC on 15 Aug:

2:29 AM if i have a --HEAD formula installed, how do i also install the release version so i can switch between them with brew link?
5:36 AM Habbie:
5:36 AM mv /usr/local/Cellar/hub{,.head}
5:36 AM brew install hub
5:36 AM unlink before mv i presume
5:36 AM mv /usr/local/Cellar/hub{.head/*,}
5:37 AM rmdir /usr/local/Cellar/hub.head
5:37 AM then u can switch back and forth
5:37 AM ack
5:37 AM i was hoping for something cleaner ;)
5:37 AM thanks
5:37 AM it does work with brew switch then
5:37 AM i have abandoned the whole project i needed it for by now
5:37 AM oh switch takes a version, that's useful
5:38 AM right.
5:38 AM Josephs-MacBook-Pro:~ joe$ brew switch hub 2.2.5
5:38 AM Cleaning /usr/local/Cellar/hub/2.2.5
5:38 AM Cleaning /usr/local/Cellar/hub/HEAD-ddd5b16
5:38 AM 6 links created for /usr/local/Cellar/hub/2.2.5
5:39 AM Josephs-MacBook-Pro:~ joe$ brew switch hub HEAD-ddd5b16
5:39 AM Cleaning /usr/local/Cellar/hub/2.2.5
5:39 AM Cleaning /usr/local/Cellar/hub/HEAD-ddd5b16
5:39 AM 4 links created for /usr/local/Cellar/hub/HEAD-ddd5b16
5:39 AM :)
5:39 AM it's just convincing it to install stable ...

[mrzv]

@ilovezfs In other words, unlink, move out from the Cellar, install the desired version, move the other one back into the Cellar?

[ilovezfs]

yep. Then brew switch will let you go back and forth between them.

[mrzv]

Got you. Thanks.

[ilovezfs]

You're welcome!

[mrzv]

Ok, building 3.2 from source gives the same segfault. I think I'll report this upstream.

[ilovezfs]

@mrzv Right that's what I saw too:

However, simply rebuilding the bottle doesn't help

But since it doesn't happen in HEAD, your report needs to nag them for a new release tag as soon as possible.

Also, did you try building from source with gcc? That fixed it for me. brew install gcc and pass --cc=gcc-6, or add fails_with :clang to the formula.

[mrzv]

I did not, but HEAD seems to work fine with the same compiler. Actually, now that I think about it, building both from source gave me a warning:

Warning: mpich dependency gcc was built with a different C++ standard
library (libstdc++ from clang). This may cause problems at runtime.

But again, the build of HEAD didn't care.

[mrzv]

Checked upstream. They know about the problem, meaning it will be fixed in the next bugfix release. Meanwhile, alignment.patch fixes the problem in the current release.

[ilovezfs]

@mrzv the bottles should be fixed now!

[mrzv]

Indeed, 3.2_2 works for me. Thanks!

[ilovezfs]

@mrzv excellent. Thank you for following up and testing that it was indeed fixed!