[gmx-users] Seg Fault with Gromacs gmx grompp command - Intel compiler

Mark Abraham mark.j.abraham at gmail.com
Sun Dec 8 14:35:53 CET 2019 

Hi,

That's clearly a mismatch between the std library headers used at compile
time and the one used at (dynamic) linking time. I don't know how to fix
it, but on such systems, I've always resorted to scl environments to get
the appropriate gcc compiler+libraries, and if so then that would be the
right time to source the Intel scripts.

Mark

On Sun, 8 Dec 2019 at 00:56, Glenn (Gedaliah) Wolosh <gwolosh at njit.edu>
wrote:

> Here ya go
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00002aaab21e63aa in
> std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) ()
>     at ../../../../../gcc-5.4.0/libstdc++-v3/src/c++98/tree.cc:98 <
> http://tree.cc:98/>
> 98      ../../../../../gcc-5.4.0/libstdc++-v3/src/c++98/tree.cc <
> http://tree.cc/>: No such file or directory.
>         in ../../../../../gcc-5.4.0/libstdc++-v3/src/c++98/tree.cc <
> http://tree.cc/>
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.12-1.212.el6.x86_64
> (gdb) bt
> #0  0x00002aaab21e63aa in
> std::local_Rb_tree_decrement(std::_Rb_tree_node_base*) ()
>     at ../../../../../gcc-5.4.0/libstdc++-v3/src/c++98/tree.cc:98 <
> http://tree.cc:98/>
> #1  0x00002aaab1103c03 in std::_Rb_tree<unsigned char, std::pair<unsigned
> char const, void (*)(gmx::KeyValueTreeValueBuilder*, gmx
> ::ISerializer*)>, std::_Select1st<std::pair<unsigned char const, void
> (*)(gmx::KeyValueTreeValueBuilder*, gmx::ISerializer*)> >, s
> td::less<unsigned char>, std::allocator<std::pair<unsigned char const,
> void (*)(gmx::KeyValueTreeValueBuilder*, gmx::ISerializer*)
> > >
> >::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator<std::pair<unsigned
> char const, void (*)(gmx::KeyValueTreeValueBu
> ilder*, gmx::ISerializer*)> >, unsigned char const&) ()
>    from /afs/
> cad.njit.edu/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4 <
> http://cad.njit.edu/linux/gromacs/intel/2019.4/lib64/libgromacs.so.4>
> #2  0x00002aaab11011f0 in gmx::(anonymous
> namespace)::ValueSerializer::initSerializers() ()
>    from /afs/
> cad.njit.edu/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4 <
> http://cad.njit.edu/linux/gromacs/intel/2019.4/lib64/libgromacs.so.4>
> #3  0x00002aaab10ffee2 in
> gmx::serializeKeyValueTree(gmx::KeyValueTreeObject const&,
> gmx::ISerializer*) ()
>    from /afs/
> cad.njit.edu/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4 <
> http://cad.njit.edu/linux/gromacs/intel/2019.4/lib64/libgromacs.so.4>
> #4  0x00002aaab115ca27 in _INTERNAL2c7c030d::do_inputrec(t_fileio*,
> t_inputrec*, bool, int) ()
>    from /afs/
> cad.njit.edu/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4 <
> http://cad.njit.edu/linux/gromacs/intel/2019.4/lib64/libgromacs.so.4>
> #5  0x00002aaab1154df1 in _INTERNAL2c7c030d::do_tpx(t_fileio*, bool,
> t_inputrec*, t_state*, float (*) [3], float (*) [3], gmx_mtop_t*) () from
> /afs/cad.njit.edu/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4
> <http://cad.njit.edu/linux/gromacs/intel/2019.4/lib64/libgromacs.so.4>
> #6  0x00002aaab11548ed in write_tpx_state(char const*, t_inputrec const*,
> t_state const*, gmx_mtop_t const*) ()
>    from /afs/
> cad.njit.edu/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4 <
> http://cad.njit.edu/linux/gromacs/intel/2019.4/lib64/libgromacs.so.4>
> #7  0x00002aaab132cae4 in gmx_grompp(int, char**) ()
>    from /afs/
> cad.njit.edu/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4 <
> http://cad.njit.edu/linux/gromacs/intel/2019.4/lib64/libgromacs.so.4>
> #8  0x00002aaab1039549 in gmx::CommandLineModuleManager::run(int, char**)
> ()
>    from /afs/
> cad.njit.edu/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4 <
> http://cad.njit.edu/linux/gromacs/intel/2019.4/lib64/libgromacs.so.4>
> #9  0x0000000000407928 in main ()
>
> GW
>
> > On Dec 6, 2019, at 9:39 AM, Mark Abraham <mark.j.abraham at gmail.com>
> wrote:
> >
> > OK, that looks fine.
> >
> > What does the stack trace of the segfault look like? e.g.
> >
> > gdb --args /the/gmx grompp -whatever -args
> >
> > Mark
> >
> > On Fri, 6 Dec 2019 at 15:29, Glenn (Gedaliah) Wolosh <gwolosh at njit.edu
> <mailto:gwolosh at njit.edu>>
> > wrote:
> >
> >>
> >>
> >>> On Dec 6, 2019, at 9:12 AM, Mark Abraham <mark.j.abraham at gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> If the environment is sufficiently well constructed to do the necessary
> >>> dynamic linking, then things like gmx -version and gmx editconf should
> >> not
> >>> segfault. Do they? My guess is that the appropriate Intel libraries, or
> >>> perhaps the gcc libstdc++ libraries that icc requires are actually not
> >>> available in the environment.
> >>
> >>
> >> These command do not segfault. The dynamic linking is fine.
> >>
> >> kong-183 lysozyme >: module list
> >> Currently Loaded Modulefiles:
> >>  1) sge                            3) intel/parallel_studio/2019.4   5)
> >> gromacs/intel/2019.4
> >>  2) singularity/3.2.1              4) gcc/5.4.0
> >>
> >> kong-184 lysozyme >: which gmx
> >> /afs/cad/linux/gromacs/intel/2019.4/bin/gmx
> >> kong-185 lysozyme >: ldd /afs/cad/linux/gromacs/intel/2019.4/bin/gmx
> >>        linux-vdso.so.1 =>  (0x00007ffd08584000)
> >>        libmkl_intel_lp64.so =>
> >>
> /afs/cad/linux/intel/parallel_studio_cluster_edition_2019.4/compilers_and_libraries_2019.4.243/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so
> >> (0x00002afa6906e000)
> >>        libmkl_sequential.so =>
> >>
> /afs/cad/linux/intel/parallel_studio_cluster_edition_2019.4/compilers_and_libraries_2019.4.243/linux/mkl/lib/intel64_lin/libmkl_sequential.so
> >> (0x00002afa69be6000)
> >>        libmkl_core.so =>
> >>
> /afs/cad/linux/intel/parallel_studio_cluster_edition_2019.4/compilers_and_libraries_2019.4.243/linux/mkl/lib/intel64_lin/libmkl_core.so
> >> (0x00002afa6b180000)
> >>        libgromacs.so.4 =>
> >> /afs/cad/linux/gromacs/intel/2019.4/bin/../lib64/libgromacs.so.4
> >> (0x00002afa6f455000)
> >>        libm.so.6 => /lib64/libm.so.6 (0x00000038cc400000)
> >>        libstdc++.so.6 =>
> >> /afs/cad/linux/gcc-5.4.0-sl6/lib64/libstdc++.so.6 (0x00002afa706fe000)
> >>        libiomp5.so =>
> >>
> /afs/cad/linux/intel/parallel_studio_cluster_edition_2019.4/compilers_and_libraries_2019.4.243/linux/compiler/lib/intel64_lin/libiomp5.so
> >> (0x00002afa70a8c000)
> >>        libgcc_s.so.1 => /afs/cad/linux/gcc-5.4.0-sl6/lib64/libgcc_s.so.1
> >> (0x00002afa70e76000)
> >>        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038cbc00000)
> >>        libc.so.6 => /lib64/libc.so.6 (0x00000038cb800000)
> >>        libdl.so.2 => /lib64/libdl.so.2 (0x00000038cc000000)
> >>        librt.so.1 => /lib64/librt.so.1 (0x00000038cc800000)
> >>        libimf.so =>
> >>
> /afs/cad/linux/intel/parallel_studio_cluster_edition_2019.4/compilers_and_libraries_2019.4.243/linux/compiler/lib/intel64_lin/libimf.so
> >> (0x00002afa7108e000)
> >>        libsvml.so =>
> >>
> /afs/cad/linux/intel/parallel_studio_cluster_edition_2019.4/compilers_and_libraries_2019.4.243/linux/compiler/lib/intel64_lin/libsvml.so
> >> (0x00002afa7162f000)
> >>        libirng.so =>
> >>
> /afs/cad/linux/intel/parallel_studio_cluster_edition_2019.4/compilers_and_libraries_2019.4.243/linux/compiler/lib/intel64_lin/libirng.so
> >> (0x00002afa72fd3000)
> >>        libintlc.so.5 =>
> >>
> /afs/cad/linux/intel/parallel_studio_cluster_edition_2019.4/compilers_and_libraries_2019.4.243/linux/compiler/lib/intel64_lin/libintlc.so.5
> >> (0x00002afa73345000)
> >>        /lib64/ld-linux-x86-64.so.2 (0x00005613d5ea5000)
> >>
> >> This seems specific to the Scientific Linux 6.x OS.  When built and
> >> installed on a 7.x version, cmx grompp works fine.
> >>
> >> GW
> >>
> >>
> >>
> >>>>>
> >>>>> On Thu, 5 Dec 2019 at 20:22, Glenn (Gedaliah) Wolosh <
> gwolosh at njit.edu
> >>>> <mailto:gwolosh at njit.edu <mailto:gwolosh at njit.edu> <mailto:
> gwolosh at njit.edu <mailto:gwolosh at njit.edu>>>>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> Also posted on the intel forum:
> >>>>>>
> >>>>>> This problem is consistent with the following gromacs/compiler
> >> versions:
> >>>>>>
> >>>>>> Gromacs 2019.4/Intel Parallel Studio 2019.4
> >>>>>>
> >>>>>> Gromacs 2019.4/Intel 2017.2
> >>>>>>
> >>>>>> Gromacs 2018.2/Intel Parallel Studio 2019.4
> >>>>>>
> >>>>>> Gromacs 2018.5/Intel Parallel Studio 2019.4
> >>>>>>
> >>>>>> The command to build and install gromacs in all cases is
> >>>>>>
> >>>>>> export CC=icc
> >>>>>> export CXX=icpc
> >>>>>> export FC=ifort
> >>>>>>
> >>>>>> cmake ..  -DGMX_FFT_LIBRARY=mkl \
> >>>>>>
> >> -DCMAKE_INSTALL_PREFIX=$HOME/sw/gromacs/intel/<version>
> >>>>>> &&  make VERBOSE=1 && make install
> >>>>>>
> >>>>>> The gcc version in the PATH is 5.4.0
> >>>>>>
> >>>>>> The OS is:
> >>>>>>
> >>>>>> Scientific Linux release 6.10 (Carbon)
> >>>>>>
> >>>>>> I am running the lysozyme tutorial:
> >>>>>> http://www.mdtutorials.com/gmx/lysozyme/ <
> http://www.mdtutorials.com/gmx/lysozyme/> <
> >>>>>> http://www.mdtutorials.com/gmx/lysozyme/ <
> http://www.mdtutorials.com/gmx/lysozyme/> <
> >>>> http://www.mdtutorials.com/gmx/lysozyme/ <
> http://www.mdtutorials.com/gmx/lysozyme/> <
> >> http://www.mdtutorials.com/gmx/lysozyme/ <
> http://www.mdtutorials.com/gmx/lysozyme/>>>>
> >>>>>> The command that seg faults is
> >>>>>>
> >>>>>> gmx grompp -f ions.mdp -c 1AKI_solv.gro -p topol.top <
> http://topol.top/> -o ions.tpr
> >>>> -maxwarn 2
> >>>>>>
> >>>>>> The gmx grompp command succeeds when using a version of gromacs
> >> compiled
> >>>>>> with GCC
> >>>>>>
> >>>>>> Any help would be greatly appreciated.
> >>>>>>
> >>>>>>
> >>>>>> GW
> >>>>>> --
> >>>>>> Gromacs Users mailing list
> >>>>>>
> >>>>>> * Please search the archive at
>
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.
>

More information about the gromacs.org_gmx-users mailing list