Faculty of Science, UJEP
Dear Liggghts community,
during one larger modification, we have discovered one really nasty bug,
which can lead to some weird behaviours in some cases:
In
fix_contact_history.cpp
and
fix_contact_history_mesh.cpp
some allocations to MyPage class are missing correct page sizes.
As one can see in correct definition in neigh_list.cpp,
dpage[i].init(dnum*oneatom,dnum*pgsize,PGDELTA);
when init to MyPage has dnum members, pgsize should enlarge accordingly, but that is not the case.
Bug fixes:
fix_contact_history.cpp
dpage_[i].init(oneatom_*std::max(1,dnum_),pgsize_); -> dpage_[i].init(oneatom_*std::max(1,dnum_),pgsize_*std::max(1,dnum_));
fix_contact_history_mesh.cpp:
dpage1_[i].init(oneatom_*std::max(1,dnum_),pgsize_); -> dpage1_[i].init(oneatom_*std::max(1,dnum_),pgsize_*std::max(1,dnum_));
dpage2_[i].init(oneatom_*std::max(1,dnum_),pgsize_); -> dpage2_[i].init(oneatom_*std::max(1,dnum_),pgsize_*std::max(1,dnum_));
mschramm | Mon, 08/31/2020 - 19:24
Questions about bug
Are the behaviors obvious from this bug?
Thank you for finding this.
martin.kozakovic | Tue, 09/01/2020 - 10:51
Some larger systems ended
Some larger systems ended with segmentation faults right away, some continued even when memory was not properly alocated and some produced good results and some nonsense. The bug can be verified by adding some prints into my_page.h init function, where one can see, that when pagesize is smaller than it should be (maxchunk > pagesize), bad state is returned and allocation is never done. Tested with around 18 - 20 history parameters.
Daniel Queteschiner | Tue, 09/08/2020 - 18:15
Work around
There should indeed be a check of the function's return value, terminating the program upon errors; however, it should be possible to work around the issue by using the
page
andone
options of theneigh_modify
command as documented in the manual ...