CREST Hessian calculations segfault on diatoms

[jevandezande]

Segfaults in v3.0.2 but not v3.0.1

To Reproduce

2
H₂
H 0 0 0
H 0 0 1

crest geom.xyz --ohess or crest geom.xyz --numhess

[pprcht]

I cannot reproduce this, both ifort and gfortran builds work fine without segfault.

Any more information? What's the segfault message? Are you using a self-built binary, or a precompiled one?

[jevandezande]

I'm using the conda version of CREST on Ubuntu 24.04 with a AMD Ryzen 7 7840HS.

Error:

*** stack smashing detected ***: terminated

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x786fd344531f in ???
	at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#1  0x786fd349eb1c in __pthread_kill_implementation
	at ./nptl/pthread_kill.c:44
#2  0x786fd349eb1c in __pthread_kill_internal
	at ./nptl/pthread_kill.c:78
#3  0x786fd349eb1c in __GI___pthread_kill
	at ./nptl/pthread_kill.c:89
#4  0x786fd344526d in __GI_raise
	at ../sysdeps/posix/raise.c:26
#5  0x786fd34288fe in __GI_abort
	at ./stdlib/abort.c:79
#6  0x786fd34297b5 in __libc_message_impl
	at ../sysdeps/posix/libc_fatal.c:132
#7  0x786fd3536c18 in __GI___fortify_fail
	at ./debug/fortify_fail.c:24
#8  0x786fd3537ea3 in __stack_chk_fail
	at ./debug/stack_chk_fail.c:24
#9  0x577064beb0f2 in getsymmetry2_
	at /usr/local/src/conda/crest-3.0.2/src/symmetry2.f90:135
#10  0x577064a52495 in prepthermo_
	at /usr/local/src/conda/crest-3.0.2/src/entropy/thermocalc.f90:74
#11  0x577064a52ef9 in calcthermo_
	at /usr/local/src/conda/crest-3.0.2/src/entropy/thermocalc.f90:280
#12  0x577064810075 in numhess_thermostat_
	at /usr/local/src/conda/crest-3.0.2/src/algos/numhess.f90:313
#13  0x57706482c8f2 in crest_numhess_
	at /usr/local/src/conda/crest-3.0.2/src/algos/numhess.f90:207
#14  0x5770647bbd1f in crest
	at /usr/local/src/conda/crest-3.0.2/src/crest_main.f90:279
#15  0x5770647ba280 in main
	at /usr/local/src/conda/crest-3.0.2/src/crest_main.f90:26

Output:

       ╔════════════════════════════════════════════╗
       ║            ___ ___ ___ ___ _____           ║
       ║           / __| _ \ __/ __|_   _|          ║
       ║          | (__|   / _|\__ \ | |            ║
       ║           \___|_|_\___|___/ |_|            ║
       ║                                            ║
       ║  Conformer-Rotamer Ensemble Sampling Tool  ║
       ║          based on the xTB methods          ║
       ║                                            ║
       ╚════════════════════════════════════════════╝
       Version 3.0.2, Thu, 29 August 14:20:46, 08/29/2024
       commit (65685a7) compiled by 'usr@d37571da525e'

   Cite work conducted with this code as

   • P.Pracht, F.Bohle, S.Grimme, PCCP, 2020, 22, 7169-7192.
   • S.Grimme, JCTC, 2019, 15, 2847-2862.
   • P.Pracht, S.Grimme, C.Bannwarth, F.Bohle, S.Ehlert,
     G.Feldmann, J.Gorges, M.Müller, T.Neudecker, C.Plett,
     S.Spicher, P.Steinbach, P.Wesołowski, F.Zeller,
     J. Chem. Phys., 2024, 160, 114110.

   for works involving QCG cite

   • S.Spicher, C.Plett, P.Pracht, A.Hansen, S.Grimme,
     JCTC, 2022, 18 (5), 3174-3189.
   • C.Plett, S. Grimme,
     Angew. Chem. Int. Ed. 2023, 62, e202214477.

   for works involving MECP screening cite

   • P.Pracht, C.Bannwarth, JCTC, 2022, 18 (10), 6370-6385.

   Original code
     P.Pracht, S.Grimme, Universität Bonn, MCTC
   with help from (alphabetical order):
     C.Bannwarth, F.Bohle, S.Ehlert, G.Feldmann, J.Gorges,
     S.Grimme, C.Plett, P.Pracht, S.Spicher, P.Steinbach,
     P.Wesolowski, F.Zeller

   Online documentation is available at
   https://crest-lab.github.io/crest-docs/

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
   GNU Lesser General Public License (LGPL) for more details.

 Command line input:
 $ crest geom.xyz --numhess


> Setting up backup calculator ... done.
 ----------------
 Calculation info
 ----------------
> User-defined calculation level:
 : xTB calculation via tblite lib
 : GFN2-xTB level
 :   Molecular charge    : 0
 :   Fermi temperature   : 300.00000
 :   Accuracy            : 1.00000
 :   max SCC cycles      : 500


                        _
  _ __  _   _ _ __ ___ | |__   ___  ___ ___
 | '_ \| | | | '_ ` _ \| '_ \ / _ \/ __/ __|
 | | | | |_| | | | | | | | | |  __/\__ \__ \
 |_| |_|\__,_|_| |_| |_|_| |_|\___||___/___/


 Input structure:
  2

 H          0.0000000000        0.0000000000       -0.4500000000
 H          0.0000000000        0.0000000000        0.4500000000

 ----------------
 Calculation info
 ----------------
> User-defined calculation level:
 : xTB calculation via tblite lib
 : GFN2-xTB level
 :   Molecular charge    : 0
 :   Fermi temperature   : 300.00000
 :   Accuracy            : 1.00000
 :   max SCC cycles      : 500

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 Initial singlpoint calculation ...
 -------------------------------------
 Energy =        -0.976927419520814 Eh
 -------------------------------------
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 Calculating numerical Hessian ... done.

 Will be written to file "numhess1" ...

[pprcht]

Interesting. This doesn't reveal too much, unfortunately. The error seems to result from one of the C/Fortran interfaced routines, but doesn't tell what exactly goes wrong. My best guess is the passing of strings between the two languages which somehow causes the stack smashing. Might be some time until I find out what goes wrong.
Also, debugging & reproducing the conda build is a bit more complicated.