[Wien] SIGSEGV, segmentation fault occurred!
Gerhard Fecher
fecher at uni-mainz.de
Tue Apr 1 11:04:13 CEST 2008
The problems with dynamic linking seem to appear sometimes but
I could not figure out why, it seems to depend strongly on the Linux and Compiler versions.
Probably there is some incompatibility with different library Versions,
in that case you have to check the output about what is missing.
If it works with the options you used, then its fine.
Note, -lmkl_lapack -lmkl_ia32 are always the static versions, the dynamic have different names.
you may try
-L/opt/intel/fc/xxxx/lib -lsvml -lguide -lpthread
-L/opt/intel/mkl/xxxx/lib/32 -lmkl_lapack -lmkl_ia32 -lguide -lpthread
This should link everything dynamic but not the lapack/mkl libraries and is -from my experience at least- the most stable version.
Gerhard
________________________________________
Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] im Auftrag von hongch [hongch at hiroshima-u.ac.jp]
Gesendet: Dienstag, 1. April 2008 18:39
An: A Mailing list for WIEN2k users
Betreff: Re: [Wien] SIGSEGV, segmentation fault occurred!
Very thanks Gerhard Fecher.
I have downgrade mkl to 9.1 version and now it looks work well.
I try to compile as dynamic. I use the some parameter as you write in a
reference,but it always fail,why??? so , at last , I compile with the
former option parameter.
PS: "Why do you use the 32-bit libraries if you have an em64t system ?"
I just install 32-bit fedora 8.0 system(it is maybe unsuitable).
On Sat, 2008-03-29 at 09:16 +0100, Gerhard Fecher wrote:
> Both, youre ifort and mkl versions have still bugs or at least some problems with Wien, see my earlier comments in that forum.
> I suggest to downgrade to the more stable versions: ifort 10.0 mkl 9.1,
> both are avalable for free from the Intel webpage.
>
> Why do you use the 32-bit libraries if you have an em64t system ?
> The 2 GByte restiction does not appear for the em64t versions of libpthread.
>
> Why do you need any static linking, do you intend to distribute the program to computers were the ifort and mkl are not installed ?
> If you do not then don't use it.
>
> For those that still belive in the ulimit, see below.
>
> Gerhard
>
> The {\scshape Intel} homepage tells:}
> \label{sec:tiht}
>
> The {\scshape Intel} Fortran Compilers 8.0 or higher allocate more
> temporaries on the stack than previous {\scshape Intel} Fortran
> compilers. Temporaries include automatic arrays and array sub-sections
> corresponding to actual arguments. If the program is not afforded
> adequate stack space at runtime relative to the total size of the
> temporaries, the program will terminate with a segmentation fault on
> {\scshape Linux}. On {\scshape Linux}, the stack space can be increased
> using (e.g. {\it ulimit -s unlimited}) for bash shell or (e.g. {\it
> limit stacksize unlimited}) for csh shell.
>
> For {\scshape Intel} Fortran Compilers 10.0: The heap-arrays compiler
> option directs the compiler to put the automatic arrays and arrays
> created for temporary computations on the heap instead of the stack.
>
> Note: The size of {\it "unlimited"} varies by {\scshape Linux}
> configuration, so you may need to specify a larger, specific number to
> {\it ulimit} (for example, 999999999). On {\scshape Linux} also note
> that many 32bit {\scshape Linux} distributions ship with a pthread
> static library ({\it libpthread.a}) that at runtime will fix the
> stacksize to 2093056 bytes regardless of the {\it ulimit} setting. To
> avoid this problem do not link with the {\it -static} option or the
> {\it -fast} option. Instead of {\it -fast}, use options: {\it -ipo -O3
> -no-prec-div -xP}. This only affects the 32bit {\scshape Linux}
> distributions and does not apply to the 64bit {\scshape Linux}
> distributions.
>
> ________________________________________
> Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at zeus.theochem.tuwien.ac.at] im Auftrag von hongch [hongch at hiroshima-u.ac.jp]
> Gesendet: Freitag, 28. März 2008 20:57
> An: wien at zeus.theochem.tuwien.ac.at
> Betreff: [Wien] SIGSEGV, segmentation fault occurred!
>
> I have search the mail-list ,this problem maybe cause by using
> unsuitable compile parameters.
> But I have successful compiled the wien2k08 with the arguments:
>
> O Compiler options: -FR -mp1 -w -prec_div -pc80 -pad -ipo
> -DINTEL_VML -O3 -xT -threads -traceback
> L Linker Flags: -L/opt/intel/fc/10.1.012/lib -Bstatic
> -lguide -lguide_stats -lsvml -Bdynamic -lpthread
> P Preprocessor flags '-DParallel'
> R R_LIB (LAPACK+BLAS): -L/opt/intel/mkl/10.0.1.014/lib/32
> -Bstatic -lmkl_lapack -lmkl_ia32 -lguide -Bdynamic -lpthread
> for my system intel core2 qudra 6600, and the compiler is
> ifc 10.1.012 ; mkl 10.1.012.
>
> after compile, I have running a simple structure fcc Pb, and there is no
> any error occurred.
> but when I construct a more complex structure Pb-surface ,in the first
> it also running well and converge at last.
> but when I running the MINI the error "SIGSEGV, segmentation fault"
> occurred!
> It show:
> LAPW0 END
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image PC Routine Line
> Source
> . 40000402 Unknown Unknown Unknown
> lapw1 084619DB Unknown Unknown Unknown
> libpthread.so.0 0010650B Unknown Unknown Unknown
> libc.so.6 00D3CB2E Unknown Unknown Unknown
> > stop error
> then I delete all the files except .struct and .inst file and try to
> running with the origin structure, but this error also occurred.
>
> I am puzzle , it is bug for the compile or others.
> PS: theOMP_NUM_THEADS=1
> "ulimit...."have used in .bashrc.
>
>
>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
More information about the Wien
mailing list