Re: [moose-generic] MOOSE_installation_problem

[Vadim A <ast...@nc...>]

Hi Subha.

I try everything but still getting segmentation fault.



  I am pointing to new "numpy" compiled with gnu 

export LD_LIBRARY_PATH=/home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages:$LD_LIBRARY_PATH

and modified Makefile to point to the new lib:

PYTHON_INCLUDES := -I/home/diag/opt/python2.7/include/python2.7 -I/home/diag/opt/python2.7/include/python2.7 -I/home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages/numpy/core/include/




gdb shows me that new "gnulib" become used  but still segmentation foult from "libc.so"


Reading symbols from /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so...(no debugging symbols found)...done.
Loaded symbols for /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so
Reading symbols from /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so...(no debugging symbols found)...done.
Loaded symbols for /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so
………

Reading symbols from /home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages/numpy/random/mtrand.so...done.
Loaded symbols for /home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages/numpy/random/mtrand.so

…….
Reading symbols from /home/diag/opt/python2.7/lib/python2.7/lib-dynload/_struct.so...done.
Loaded symbols for /home/diag/opt/python2.7/lib/python2.7/lib-dynload/_struct.so
Core was generated by `python'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000344be7275e in free () from /lib64/libc.so.6






I see "intel" stuff and "gnulib" 





When I run "idd" on generated _moose.so

it shows libraries where some "gnu" some "intel" which might be a reason for problem :

/opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so (0x00002b1fa0b00000)
	/opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so (0x00002b1fa0eb3000)
	/opt/intel/Compiler/11.1/072/lib/intel64/libpdbx.so.5 (0x00002b1fa16c8000)
	/home/diag/opt/python2.7/lib/python2.7/site-packages/scipy/sparse/sparsetools/_coo.so (0x00002b1fa17ed000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b1fa1a43000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00002b1fa1c5f000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00002b1fa1e63000)
	libpython2.7.so.1.0 => /home/diag/opt/python2.7/lib/libpython2.7.so.1.0 (0x00002b1fa2066000)
	libgsl.so.0 => /home/diag/opt/gsl/1.15/gnu/lib/libgsl.so.0 (0x00002b1fa243e000)
	libgslcblas.so.0 => /home/diag/opt/gsl/1.15/gnu/lib/libgslcblas.so.0 (0x00002b1fa285e000)
	libm.so.6 => /lib64/libm.so.6 (0x00002b1fa2a97000)
	libstdc++.so.6 => /home/diag/opt/gcc/4.6.1/lib64/libstdc++.so.6 (0x00002b1fa2d1b000)
	libgcc_s.so.1 => /home/diag/opt/gcc/4.6.1/lib64/libgcc_s.so.1 (0x00002b1fa3020000)
	libc.so.6 => /lib64/libc.so.6 (0x00002b1fa3235000)
	libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00002b1fa358d000)
	libimf.so => /opt/intel/Compiler/11.1/072/lib/intel64/libimf.so (0x00002b1fa3868000)
	libsvml.so => /opt/intel/Compiler/11.1/072/lib/intel64/libsvml.so (0x00002b1fa3bfc000)
	libcxaguard.so.5 => /opt/intel/Compiler/11.1/072/lib/intel64/libcxaguard.so.5 (0x00002b1fa3e13000)
	libintlc.so.5 => /opt/intel/Compiler/11.1/072/lib/intel64/libintlc.so.5 (0x00002b1fa3f14000)
	/lib64/ld-linux-x86-64.so.2 (0x000000344ba00000)



I don't know what else we can do

Regards,

Vadim.



On Apr 5, 2013, at 11:39 PM, Subhasis Ray wrote:

> Dear Vadim,
>  I am not familiar with such cluster environment. But from what I gather on the Internet, it seems that the issue is possibly a mismatch of compilers and libraries. If your default compiler is intel, then loading python before gnu perhaps loads a Python compiled with intel compiler your default. Can you see if changing the order of loading modules helps? i.e.
> 
> module load gnu/4.6.1
> module load python
> ...
> 
> 
> Also, you can run `ldd` on generated _moose.so to list the linked libraries and add the paths to the directories containing those libraries to your LD_LIBRARY_PATH environment variable.
> 
> hth,
>   Subha
> 
> 
> 
> 
> On Sat, Apr 6, 2013 at 12:35 AM, Vadim A <ast...@nc...> wrote:
> Hi,
> 
> numpy has been compiled with gnu on our cluster and to access bumpy  we do the following:
> 
> module load python
> module load gnu/4.6.1
> export
> PYTHONPATH=/home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages:$PYT
> HONPATH
> 
> 
> 
> Should I also adjust   Makefile for MOOSE  to make sure that proper "numpy" library will be used during compilation step ?
> 
> Thanks a lot in advance for information.
> 
> Vadim.
> 
> 
> 
> 
> On Mar 28, 2013, at 2:13 AM, Subhasis Ray wrote:
> 
> > First please confirm that Python and numpy were also compiled with gcc.
> >
> > If so, then best option could be to allow somebody from here (niraj or
> > me) to login to your system (via some portal as Amitava mentioned
> > earlier in this thread) and run gdb as we cannot reproduce the error
> > on our system.
> >
> > On 3/28/13, Vadim A <ast...@nc...> wrote:
> >>
> >>
> >> On Mar 28, 2013, at 12:15 AM, Subhasis Ray wrote:
> >>
> >>> Hi,
> >>> On 3/28/13, Vadim A <ast...@nc...> wrote:
> >>>> When I compile, I always see lines with g++
> >>>>
> >>>>
> >>>> g++ -g -pthread -fpermissive -fno-strict-aliasing -fPIC
> >>>> -fno-inline-functions -Wall -Wno-long-long -pedantic -DDO_UNIT_TESTS
> >>>> -DUSE_GENESIS_PARSER -DSVN_REVISION=\"4401M\" -DLINUX -DUSE_GSL -I
> >>>> /home/diag/opt/gsl/1.15/gnu/include/    basecode/_basecode.o msg/_msg.o
> >>>> shell/_shell.o biophysics/_biophysics.o hsolve/_hsolve.o
> >>>> randnum/_randnum.o
> >>>> scheduling/_scheduling.o builtins/_builtins.o device/_device.o
> >>>> kinetics/_kinetics.o ksolve/_ksolve.o regressionTests/_rt.o
> >>>> utility/_utility.o geom/_geom.o mesh/_mesh.o manager/_manager.o
> >>>> signeur/_signeur.o     -L/usr/lib -L/usr/local/lib -lpthread -L/lib64
> >>>> -L/usr/lib64 -L/usr/lib -L/home/diag/opt/gsl/1.15/gnu/lib/ -lgsl
> >>>> -lgslcblas
> >>>> -lm -o moose
> >>>>
> >>>>
> >>>>
> >>>> That tells me that I am using g++ (which is gcc) but not Intel compiler,
> >>>> right ?
> >>>
> >>> Yes, moose is being compiled by g++
> >>>
> >>>>
> >>>> So, I kind of confused what should I do here.
> >>>>
> >>>
> >>> But what about Python libs? In your previous mail
> >>>
> >>> ----8<----------------->8---
> >>> gdb -c core.8851 /home/diag/opt/python2.7/bin/python
> >>>
> >>> Reading symbols from
> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so...(no
> >>> debugging symbols found)...done.
> >>> Loaded symbols for
> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so
> >>> Reading symbols from
> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so...(no
> >>> debugging symbols found)...done.
> >>> Loaded symbols for
> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so
> >>> Reading symbols from
> >>> /opt/intel/Compiler/11.1/072/lib/intel64/libpdbx.so.5...(no debugging
> >>> symbols found)...done.
> >>> Loaded symbols for /opt/intel/Compiler/11.1/072/lib/intel64/libpdbx.so.5
> >>> Reading symbols from
> >>> /home/diag/opt/python2.7/lib/python2.7/site-packages/scipy/sparse/sparsetools/_coo.so...(no
> >>> debugging symbols found)...done.
> >>> Loaded symbols for
> >>> /home/diag/opt/python2.7/lib/python2.7/site-packages/scipy/sparse/sparsetools/_coo.so
> >>> Reading symbols from
> >>> /home/diag/opt/python2.7/lib/libpython2.7.so.1.0...done.
> >>> Loaded symbols for /home/diag/opt/python2.7/lib/libpython2.7.so.1.0
> >>>
> >>> ----8<----------------->8---
> >>>
> >>> shows that several libraries from intel compiler are being loaded
> >>> before scipy/sparse/sparsetools/_coo.so and libpython2.7.so.
> >>>
> >>> Did you compile Python in
> >>> /home/diag/opt/python2.7/lib/libpython2.7.so.1.0 and/or numpy/scipy
> >>> from source? In that case, did you use intel compiler to compile them?
> >>>
> >>> Though this could be red herring, I do not see any reason for the
> >>> control to reach basecode/SetGet.h:289. May be a debugging session
> >>> could help.
> >>>
> >>> Best,
> >>>  Subha
> >>>
> >>
> >>
> >
> 
>