Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling 4c1e integrals - segfault/double free #91

Open
duykhoidang opened this issue Mar 31, 2023 · 1 comment
Open

Calling 4c1e integrals - segfault/double free #91

duykhoidang opened this issue Mar 31, 2023 · 1 comment

Comments

@duykhoidang
Copy link

duykhoidang commented Mar 31, 2023

          I am trying to call cint4c1e using `cint4c1e_sph(buf, shls, atm, natm, bas, nbas, env)` and `cint4c1e_sph(buf, shls, atm, natm, bas, nbas, env, NULL)`, but both versions of this call result in a segfault or double-free error. Replacing `cint4c1e_sph` with `cint2e_sph` results in working code with no segfault and the correct 2e-integrals, so I do not believe the loop structure or setup of the `buf`, `shls`, `atm`, `natm`, `bas`, `nbas`, `env` variables are causing the issue. It seems like the 4c1e overlap integral code is possibly writing memory out of bounds. Do you have this error?

Originally posted by @duykhoidang in #89 (comment)

I am trying to call cint4c1e using cint4c1e_sph(buf, shls, atm, natm, bas, nbas, env) and cint4c1e_sph(buf, shls, atm, natm, bas, nbas, env, NULL), but both versions of this call result in a segfault or double-free error. Replacing cint4c1e_sph with cint2e_sph results in working code with no segfault and the correct 2e-integrals, so I do not believe the loop structure or setup of the buf, shls, atm, natm, bas, nbas, env variables are causing the issue. It seems like the 4c1e overlap integral code is possibly writing memory out of bounds. Do you have this error?

@ilygatsika
Copy link
Contributor

ilygatsika commented Sep 11, 2023

I also had this error. My guess is that it seems like the cache_size variable value in the CINT4c1e_drv() function of cint4c1e.c should be bigger. This value is defined as

libcint/src/cint4c1e.c

Lines 282 to 283 in 7086956

size_t cache_size = MAX(leng+len0+nc*n_comp*3 + pdata_size,
nc*n_comp+envs->nf*4);

Changing this definition (as well as L273) to

size_t cache_size = MAX(leng+len0+nc*n_comp*3 + pdata_size,
                                      nc*n_comp+envs->nf*32*OF_CMPLX);

seems to resolve the segfault for me, at least for the test cases obtained by adding the following lines

from pyscf import gto
import sys
mol =  gto.M(atom="H 0 0 1; H 1 0 0; O 0 1 0", basis=str(sys.argv[1]))
natm = mol.natm; nbas = mol.nbas; atm = mol._atm; bas = mol._bas; env = mol._env
natm = ctypes.c_int(natm)
nbas = ctypes.c_int(nbas)
c_atm = atm.ctypes.data_as(ctypes.c_void_p)
c_bas = bas.ctypes.data_as(ctypes.c_void_p)
c_env = env.ctypes.data_as(ctypes.c_void_p)

somewhere around line 148 (just before the first test function) of the file test_cint4c1e.py in the test directory libcint/testsuite. The segfault did not appear in my test cases for basis sets sto-3g, cc-pvdz, aug-cc-pvdz, aug-cc-pvtz.

Furthermore, I believe in PySCF 2.3.0 the molecular integral mol.intor("int4c1e_sph", comp=1) for the water molecule and the forementioned basis can be obtained with no segfault error by declaring the variables eri and out as double * instead of double complex * in pyscf/lib/gto/fill_r_4c.c lines 29 and 73. The gto.mole.getints4c function has also been evoked with NULL optimizer cintopt = lib.c_null_ptr() because otherwise I obtained an optimizer not found error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants