Ah, yeah, that's bad on OS X. Because of the two level namespace
features of OS X, doing the provide your own malloc and free tricks
that work sometimes on Linux and Solaris don't work so well on OS X.
The malloc() strdup() finds will be the malloc() in libSystem, but
the free() that Open
Brian,
To close this one off, we found that one of our libraries has a
malloc/free that was being called from ompi. I should have looked at
the crash reporter. It reported
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x05801bfc
Thread 0 Crashed:
0 lib
Brian,
I think it's just a symbol clash. A test program linked with just
mpicxx works fine but with our typical link, it fails. I've narrowed
the problem down to a single shared library. This is from C++ and the
symbols have a namespace casa. Weeding out all the the casa stuff and
some o
That's unexpected. If you run the command 'ompi_info --all', it
should list (towards the top) things like the Bindir and Libdir. Can
you see if those have sane values? If they do, can you try running a
simple hello, world type MPI application (there's one in the OMPI
tarball). It almost
Open MPI: 1.2.3
Open MPI SVN revision: r15136
Open RTE: 1.2.3
Open RTE SVN revision: r15136
OPAL: 1.2.3
OPAL SVN revision: r15136
Prefix: /usr/local
Configured architecture: i386-apple-darwin8.10.1
Hi Brian,
1.2
Which version of Open MPI are you using?
Thanks,
Brian
On Jul 11, 2007, at 3:32 AM, Tim Cornwell wrote:
I have a problem running openmpi under OS 10.4.10. My program runs
fine under debian x86_64 on an opteron but under OS X on a number
of Mac Book and Mac Book Pros, I get the following
I have a problem running openmpi under OS 10.4.10. My program runs
fine under debian x86_64 on an opteron but under OS X on a number of
Mac Book and Mac Book Pros, I get the following immediately on
startup. This smells like a common problem but I could find anything
relevant anywhere. Ca
