libmesh-users

[Libmesh-users] segmentation fault error for testing examples on a Mac

[Kyunghoon L. <gt...@gm...>]

Hello,

I'm trying to install libmesh on a MacOS X 10.6.7, which has a gcc-4.2 compiler from Xcode 3.2.6.  I had no trouble with compiling libmesh, but I got a seg fault error for the examples. 

First, I source-compiled petsc with the following configuration option:

export PETSC_DIR=$PWD
./config/configure.py --prefix=/usr/local/share/petsc/petsc-3.1-p8 --with-cc=gcc  --with-cxx=g++ --with-fc=0 —download-c-blas-lapack=1 --download-mpich=1
make
sudo make install PETSC_DIR=$PWD
make PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 test

and test results were good.  After petsc, I source-compiled an svn version of libmesh with the following configuration option:

export METHOD=dbg
./configure PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 --enable-petsc 

and had no errors during the compilation.  However, when I tried to test libmesh with the examples, I got the following message:

Makefile:69: .depend: No such file or directory
Compiling C++ (in debug mode) ex0.C...
Linking ex0-dbg...
***************************************************************
* Running Example  ./ex0-dbg
***************************************************************
 
[maclaurin-one-o-seventy-one:63325] *** Process received signal ***
[maclaurin-one-o-seventy-one:63325] Signal: Segmentation fault (11)
[maclaurin-one-o-seventy-one:63325] Signal code: Address not mapped (1)
[maclaurin-one-o-seventy-one:63325] Failing at address: 0x440000b0
[maclaurin-one-o-seventy-one:63325] [ 0] 2   libSystem.B.dylib                   0x00007fff8143666a _sigtramp + 26
[maclaurin-one-o-seventy-one:63325] [ 1] 3   ???                                 0x0000000000000000 0x0 + 0
[maclaurin-one-o-seventy-one:63325] [ 2] 4   libmesh.dylib                       0x0000000100b87a41 _ZN7libMesh5_initERiRPPci + 1277
[maclaurin-one-o-seventy-one:63325] [ 3] 5   libmesh.dylib                       0x0000000100b88e91 _ZN7libMesh11LibMeshInitC1ERiRPPci + 53
[maclaurin-one-o-seventy-one:63325] [ 4] 6   ex0-dbg                             0x00000001000036c0 main + 53
[maclaurin-one-o-seventy-one:63325] [ 5] 7   ex0-dbg                             0x0000000100002c2c start + 52
[maclaurin-one-o-seventy-one:63325] [ 6] 8   ???                                 0x0000000000000001 0x0 + 1
[maclaurin-one-o-seventy-one:63325] *** End of error message ***
make[2]: *** [run] Segmentation fault
make[1]: *** [run] Error 1
make: *** [run_examples] Error 2

I'd appreciate it if someone could help me with this problem.  

Sincerely,
K. Lee.

Re: [Libmesh-users] segmentation fault error for testing examples on a Mac

[John P. <jwp...@gm...>]

On Tue, May 31, 2011 at 1:08 PM, Kyunghoon Lee <gt...@gm...> wrote:
> Hello,
>
> I'm trying to install libmesh on a MacOS X 10.6.7, which has a gcc-4.2 compiler from Xcode 3.2.6.  I had no trouble with compiling libmesh, but I got a seg fault error for the examples.
>
> First, I source-compiled petsc with the following configuration option:
>
> export PETSC_DIR=$PWD
> ./config/configure.py --prefix=/usr/local/share/petsc/petsc-3.1-p8 --with-cc=gcc  --with-cxx=g++ --with-fc=0 —download-c-blas-lapack=1 --download-mpich=1
> make
> sudo make install PETSC_DIR=$PWD
> make PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 test
>
> and test results were good.  After petsc, I source-compiled an svn version of libmesh with the following configuration option:
>
> export METHOD=dbg
> ./configure PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 --enable-petsc

It's possible libmesh is using the wrong mpicc/mpicxx compilers when
you use this configuration line.  It will use the first one it finds
in your path, *not* the one you downloaded with PETSc.

So could you try:

CXX=/path/to/petsc/mpich/bin/mpicxx CC=/path/to/petsc/mpich/bin/mpicc
./configure

and see if you have any better luck with the executables?

-- 
John

Re: [Libmesh-users] segmentation fault error for testing examples on a Mac

[Derek G. <fri...@gm...>]

To avoid this... if you are not needing to compile any fortran then you can just use the MPI that comes with OSX (OpenMP).  Just set CC, CXX, etc to mpicc, mpicxx etc for both PetsC and libMesh... and don't tell PetsC to download mpich.

Note that we don't typically work this way.  We usually download a third party MPI (like MPICH2)... compile it and install it somewhere on our system... then set our path and compiler environment variables to point to this location and compile both PetsC and libMesh with it.  This has the nice property that it is a bit more reusable across multiple packages you might be compiling on your system.

So there are lots of options.... 

Derek

On May 31, 2011, at 1:22 PM, John Peterson wrote:

> On Tue, May 31, 2011 at 1:08 PM, Kyunghoon Lee <gt...@gm...> wrote:
>> Hello,
>> 
>> I'm trying to install libmesh on a MacOS X 10.6.7, which has a gcc-4.2 compiler from Xcode 3.2.6.  I had no trouble with compiling libmesh, but I got a seg fault error for the examples.
>> 
>> First, I source-compiled petsc with the following configuration option:
>> 
>> export PETSC_DIR=$PWD
>> ./config/configure.py --prefix=/usr/local/share/petsc/petsc-3.1-p8 --with-cc=gcc  --with-cxx=g++ --with-fc=0 —download-c-blas-lapack=1 --download-mpich=1
>> make
>> sudo make install PETSC_DIR=$PWD
>> make PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 test
>> 
>> and test results were good.  After petsc, I source-compiled an svn version of libmesh with the following configuration option:
>> 
>> export METHOD=dbg
>> ./configure PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 --enable-petsc
> 
> It's possible libmesh is using the wrong mpicc/mpicxx compilers when
> you use this configuration line.  It will use the first one it finds
> in your path, *not* the one you downloaded with PETSc.
> 
> So could you try:
> 
> CXX=/path/to/petsc/mpich/bin/mpicxx CC=/path/to/petsc/mpich/bin/mpicc
> ./configure
> 
> and see if you have any better luck with the executables?
> 
> -- 
> John
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger. 
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today. 
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] segmentation fault error for testing examples on a Mac

[Kyunghoon L. <gt...@gm...>]

>> On Tue, May 31, 2011 at 1:08 PM, Kyunghoon Lee <gt...@gm...> wrote:
>>> Hello,
>>> 
>>> I'm trying to install libmesh on a MacOS X 10.6.7, which has a gcc-4.2 compiler from Xcode 3.2.6.  I had no trouble with compiling libmesh, but I got a seg fault error for the examples.
>>> 
>>> First, I source-compiled petsc with the following configuration option:
>>> 
>>> export PETSC_DIR=$PWD
>>> ./config/configure.py --prefix=/usr/local/share/petsc/petsc-3.1-p8 --with-cc=gcc  --with-cxx=g++ --with-fc=0 —download-c-blas-lapack=1 --download-mpich=1
>>> make
>>> sudo make install PETSC_DIR=$PWD
>>> make PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 test
>>> 
>>> and test results were good.  After petsc, I source-compiled an svn version of libmesh with the following configuration option:
>>> 
>>> export METHOD=dbg
>>> ./configure PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 --enable-petsc

> On May 31, 2011, at 1:22 PM, John Peterson wrote:
>> 
>> It's possible libmesh is using the wrong mpicc/mpicxx compilers when
>> you use this configuration line.  It will use the first one it finds
>> in your path, *not* the one you downloaded with PETSc.
>> 
>> So could you try:
>> 
>> CXX=/path/to/petsc/mpich/bin/mpicxx CC=/path/to/petsc/mpich/bin/mpicc
>> ./configure
>> 
>> and see if you have any better luck with the executables?
>> 
>> -- 
>> John
>> 
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with vRanger. 
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today. 
>> http://p.sf.net/sfu/quest-sfdev2dev
>> _______________________________________________
>> Libmesh-users mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users

On May 31, 2011, at 3:28 PM, Derek Gaston wrote:

> To avoid this... if you are not needing to compile any fortran then you can just use the MPI that comes with OSX (OpenMP).  Just set CC, CXX, etc to mpicc, mpicxx etc for both PetsC and libMesh... and don't tell PetsC to download mpich.
> 
> Note that we don't typically work this way.  We usually download a third party MPI (like MPICH2)... compile it and install it somewhere on our system... then set our path and compiler environment variables to point to this location and compile both PetsC and libMesh with it.  This has the nice property that it is a bit more reusable across multiple packages you might be compiling on your system.
> 
> So there are lots of options.... 
> 
> Derek

Thanks to John, Derek, and David's help, I was able to compile petsc and libmesh successfully on my Mac.  As they pointed out, the main problem was caused by inconsistent compilers used in building petsc and libmesh.  So I tried to use the same mpicc and mpicxx compilers.  

First, I used "--download-mpich=1" option in configuring petsc.  This way I can get mpicc from petsc-3.1-p8/externalpackages/ when petsc was compiled.  However, somehow I could not get mpicxx.

Second, I used mpicc and mpicxx that come with Apple's Xcode.  I set 

export CXX=/usr/bin/mpicxx 
export CC=/usr/bin/mpicc

, but I got seg fault errors when I tested the compiled petsc with examples.

Last, I installed mpich2 separately using MacPorts such that

sudo port -v install mpich2 +default_mpi

, and then used mpicc and mpicxx from the MacPorts' mpich2 as follows:

export CXX=/opt/local/bin/mpicxx 
export CC=/opt/local/bin/mpicc

After that, I compiled petsc using the following commands.

export PETSC_DIR=$PWD
export CXX=/opt/local/bin/mpicxx 
export CC=/opt/local/bin/mpicc
./config/configure.py --prefix=/usr/local/share/petsc/petsc-3.1-p8 --with-fc=0 --download-c-blas-lapack=1
make
sudo make install PETSC_DIR=$PWD
make PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 test

(Note that I don't need Fortran, and I put the compiled petsc under /usr/local/share)

I had no errors in testing the compiled petsc.  Finally, I compiled libmesh with the following commands.

export METHOD=dbg
export CXX=/opt/local/bin/mpicxx 
export CC=/opt/local/bin/mpicc
./configure PETSC_DIR=/usr/local/share/petsc/petsc-3.1-p8 --enable-petsc  
make
make run_examples

Although I got the same warnings repetitively (plz see the below) for building libmesh and testing examples, all examples worked fine.  I really appreciate all the help from the nice guys!

Best regards,
K. Lee.

p.s.
The below is the warning messages I got for building libmesh and examples:

/opt/local/include/mpicxx.h:386: warning: unused parameter ‘oldtype’
/opt/local/include/mpicxx.h:386: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:386: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:386: warning: unused parameter ‘attr_in’
/opt/local/include/mpicxx.h:386: warning: unused parameter ‘attr_out’
/opt/local/include/mpicxx.h:388: warning: unused parameter ‘type’
/opt/local/include/mpicxx.h:388: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:388: warning: unused parameter ‘attr’
/opt/local/include/mpicxx.h:388: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:390: warning: unused parameter ‘oldtype’
/opt/local/include/mpicxx.h:390: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:390: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:1453: warning: unused parameter ‘oldcomm’
/opt/local/include/mpicxx.h:1453: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:1453: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:1453: warning: unused parameter ‘attr_in’
/opt/local/include/mpicxx.h:1453: warning: unused parameter ‘attr_out’
/opt/local/include/mpicxx.h:1454: warning: unused parameter ‘comm’
/opt/local/include/mpicxx.h:1454: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:1454: warning: unused parameter ‘attr’
/opt/local/include/mpicxx.h:1454: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:1457: warning: unused parameter ‘oldcomm’
/opt/local/include/mpicxx.h:1457: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:1457: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:1886: warning: unused parameter ‘oldwin’
/opt/local/include/mpicxx.h:1886: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:1886: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:1886: warning: unused parameter ‘attr_in’
/opt/local/include/mpicxx.h:1886: warning: unused parameter ‘attr_out’
/opt/local/include/mpicxx.h:1888: warning: unused parameter ‘win’
/opt/local/include/mpicxx.h:1888: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:1888: warning: unused parameter ‘attr’
/opt/local/include/mpicxx.h:1888: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:1890: warning: unused parameter ‘oldwin’
/opt/local/include/mpicxx.h:1890: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:1890: warning: unused parameter ‘ex’

Re: [Libmesh-users] segmentation fault error for testing examples on a Mac

[Roy S. <roy...@ic...>]

On Tue, 31 May 2011, Kyunghoon Lee wrote:

> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘oldtype’
> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘keyval’
> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘ex’
> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘attr_in’
> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘attr_out’

And these warnings pop up for effectively every libMesh object build,
too - aren't they annoying?

The default MPI stack in Ubuntu has the same issues in its headers.
These warnings don't indicate any problem more serious than "those
developers didn't worry about checking and disabling gcc warnings",
but I ended up editing the file (commenting out the legitimately
unused parameter names in the declaration headers) so that any libMesh
and/or application warnings wouldn't be buried in noise.
---
Roy

Re: [Libmesh-users] segmentation fault error for testing examples on a Mac

[Antonio C. <ant...@gm...>]

you can specity to gcc that warnings coming from outside library
should be ignored wrapping the include in a pragma

// Tell the compiler to ignore specific kind of warnings:
#pragma GCC diagnostic ignored "-Wunused-variable"
#pragma GCC diagnostic ignored "-Wunused-parameter"

#include <mpicxx.h>

// Restore compiler warnings:
#pragma GCC diagnostic warning "-Wunused-variable"
#pragma GCC diagnostic warning "-Wunused-parameter"

instead of editing the external library.

Antonio

On Wed, Jun 1, 2011 at 3:59 PM, Roy Stogner <roy...@ic...> wrote:
>
> On Tue, 31 May 2011, Kyunghoon Lee wrote:
>
>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘oldtype’
>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘keyval’
>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘ex’
>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘attr_in’
>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘attr_out’
>
> And these warnings pop up for effectively every libMesh object build,
> too - aren't they annoying?
>
> The default MPI stack in Ubuntu has the same issues in its headers.
> These warnings don't indicate any problem more serious than "those
> developers didn't worry about checking and disabling gcc warnings",
> but I ended up editing the file (commenting out the legitimately
> unused parameter names in the declaration headers) so that any libMesh
> and/or application warnings wouldn't be buried in noise.
> ---
> Roy
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
>

Re: [Libmesh-users] segmentation fault error for testing examples on a Mac

[Derek G. <fri...@gm...>]

Very cool.... do we need something like a LIBMESH_INCLUDE_NO_WARN_BEGIN and LIBMESH_INCLUDE_NO_WARN_END that could be set to compiler specific #pragmas at configure time?

Derek

On Jun 1, 2011, at 8:11 AM, Antonio Cervone wrote:

> you can specity to gcc that warnings coming from outside library
> should be ignored wrapping the include in a pragma
> 
> // Tell the compiler to ignore specific kind of warnings:
> #pragma GCC diagnostic ignored "-Wunused-variable"
> #pragma GCC diagnostic ignored "-Wunused-parameter"
> 
> #include <mpicxx.h>
> 
> // Restore compiler warnings:
> #pragma GCC diagnostic warning "-Wunused-variable"
> #pragma GCC diagnostic warning "-Wunused-parameter"
> 
> instead of editing the external library.
> 
> Antonio
> 
> On Wed, Jun 1, 2011 at 3:59 PM, Roy Stogner <roy...@ic...> wrote:
>> 
>> On Tue, 31 May 2011, Kyunghoon Lee wrote:
>> 
>>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘oldtype’
>>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘keyval’
>>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘ex’
>>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘attr_in’
>>> /opt/local/include/mpicxx.h:386: warning: unused parameter ‘attr_out’
>> 
>> And these warnings pop up for effectively every libMesh object build,
>> too - aren't they annoying?
>> 
>> The default MPI stack in Ubuntu has the same issues in its headers.
>> These warnings don't indicate any problem more serious than "those
>> developers didn't worry about checking and disabling gcc warnings",
>> but I ended up editing the file (commenting out the legitimately
>> unused parameter names in the declaration headers) so that any libMesh
>> and/or application warnings wouldn't be buried in noise.
>> ---
>> Roy
>> ------------------------------------------------------------------------------
>> Simplify data backup and recovery for your virtual environment with vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> _______________________________________________
>> Libmesh-users mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>> 
>> 

Re: [Libmesh-users] segmentation fault error for testing examples on a Mac

[Roy S. <roy...@ic...>]

On Wed, 1 Jun 2011, Derek Gaston wrote:

> Very cool.... do we need something like a
> LIBMESH_INCLUDE_NO_WARN_BEGIN and LIBMESH_INCLUDE_NO_WARN_END that
> could be set to compiler specific #pragmas at configure time?

That sounds like a pretty nice idea.  Even after going so far as to
edit my local MPI headers, I haven't gotten around to doing the same
for (different problems in) the VTK headers...

I'd worry a bit about disabling warnings this way, though.  If you're
instantiating a template or a macro that's defined in a header, for
instance, and there's something wrong with your instantiation, does
disabling warnings for the header also disable the warning about your
own mistake?
---
Roy

Re: [Libmesh-users] segmentation fault error for testing examples on a Mac

[Antonio C. <ant...@gm...>]

you should select carefully what type of warnings to disable in this way.
in my example i turned off warnings only for unused variables and
parameters that in general should not pose any serious threat to your
code (in fact i cannot imagine an example in which such approach would
fail, do you have one? i'd really be interested).

antonio

On Wed, Jun 1, 2011 at 4:28 PM, Roy Stogner <roy...@ic...> wrote:
>
> On Wed, 1 Jun 2011, Derek Gaston wrote:
>
>> Very cool.... do we need something like a
>> LIBMESH_INCLUDE_NO_WARN_BEGIN and LIBMESH_INCLUDE_NO_WARN_END that
>> could be set to compiler specific #pragmas at configure time?
>
> That sounds like a pretty nice idea.  Even after going so far as to
> edit my local MPI headers, I haven't gotten around to doing the same
> for (different problems in) the VTK headers...
>
> I'd worry a bit about disabling warnings this way, though.  If you're
> instantiating a template or a macro that's defined in a header, for
> instance, and there's something wrong with your instantiation, does
> disabling warnings for the header also disable the warning about your
> own mistake?
> ---
> Roy
>