Same input script; work well in 23 Jun 2022, Segmentation fault (core dumped) in 28 Mar 2023 version

Hi everyone, i have a new problem which is really weired.
I have a input script which works well in 23 Jun 2022,
but when i tried to run the same input script in 28 Mar 2023 version of lammps;
i always got the error: Segmentation fault (core dumped)
anyone have a idea for this case?
thanks for your time and help (1.9 KB) (3.5 MB)


Setting up Verlet run ...
  Unit style    : si
  Current step  : 0
  Time step     : 1e-08
WARNING: Communication cutoff 0.012366896070086016 is shorter than a bond length based estimate of 166.93141166368335. This may lead to errors. (../comm.cpp:723)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000664d14 in LAMMPS_NS::MyPage<double>::get (this=0x129e1b8, 
    n=<optimized out>) at ../my_page.cpp:131
131	  page = pages[ipage];
Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.x86_64
(gdb) where
#0  0x0000000000664d14 in LAMMPS_NS::MyPage<double>::get (this=0x129e1b8, 
    n=<optimized out>) at ../my_page.cpp:131
#1  0x0000000000957fc6 in LAMMPS_NS::FixNeighHistory::post_neighbor (
    this=0x103cba0) at ../fix_neigh_history.cpp:628
#2  0x0000000000555bb2 in LAMMPS_NS::Modify::setup_post_neighbor (
    this=0xf8dc70) at ../modify.cpp:355
#3  0x00000000007ed450 in LAMMPS_NS::Verlet::setup (this=0xf93970, flag=1)
    at ../verlet.cpp:130
#4  0x00000000004926bb in LAMMPS_NS::Run::command (this=0x103c870, narg=1, 
    arg=0xf96940) at ../run.cpp:171
#5  0x0000000000418e75 in LAMMPS_NS::Input::execute_command (
    this=this@entry=0xf77e70) at ../input.cpp:853
#6  0x00000000004190ec in LAMMPS_NS::Input::file (this=0xf77e70)
    at ../input.cpp:302
#7  0x000000000040be88 in main (argc=<optimized out>, argv=<optimized out>)
    at ../main.cpp:105
==24837== Invalid read of size 8
==24837==    at 0x664D14: LAMMPS_NS::MyPage<double>::get(int) (my_page.cpp:131)
==24837==    by 0x957FC5: LAMMPS_NS::FixNeighHistory::post_neighbor() (fix_neigh_history.cpp:628)
==24837==    by 0x555BB1: LAMMPS_NS::Modify::setup_post_neighbor() (modify.cpp:355)
==24837==    by 0x7ED44F: LAMMPS_NS::Verlet::setup(int) (verlet.cpp:130)
==24837==    by 0x4926BA: LAMMPS_NS::Run::command(int, char**) (run.cpp:171)
==24837==    by 0x418E74: LAMMPS_NS::Input::execute_command() (input.cpp:853)
==24837==    by 0x4190EB: LAMMPS_NS::Input::file() (input.cpp:302)
==24837==    by 0x40BE87: main (main.cpp:105)
==24837==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

You have a segmentation fault due to memory corruption because of this line:

neigh_modify exclude molecule/intra all delay 0 every 1 one 20000000 page 2000000000

Why do you use such unusually large values when your system has effectively no non-bonded interactions and thus no neighbors in the neighbor lists? This just reserves huge amounts of unused address space.

The difference between the two LAMMPS versions is because there were some changes in the data structures, so the corrupted data is in a different location. With the older LAMMPS version it was in an unused memory region, but with the current LAMMPS version some used memory is corrupted.

With the default settings for neighbor list pages, the memory consumption drops from ~4.5GB RAM to ~25MB.

Thanks for your response and help, now i can see the reason, it works and very helpful. the lastest verison of lammps have something useful to me.

I use such large values since i had some problems which are related to lower values of one and page. But I will be careful for that. Thanks

Thanks for your help, although i am not really pretty sure the meaning of these sentences. but still thanks for your reponse.