-
Notifications
You must be signed in to change notification settings - Fork 133
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
Dangling std::string pointers in mesh class #203
Comments
StefanBruens
referenced
this issue
Dec 20, 2024
bcnames are now stored in FaceDescriptor (as string members, no pointers), so the name mapping must be applied to materials/bcnames (depending on the mesh dimension).
Analysis for this case is not fully correct, the problem found by valgrind comes from some invalid code in netgen/libsrc/meshing/boundarylayer.cpp Lines 716 to 728 in 975414c
|
StefanBruens
added a commit
to StefanBruens/netgen
that referenced
this issue
Dec 20, 2024
When AddFaceDescriptor reallocates the array the fd reference becomes dangling. See NGSolve#203
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The boundarylayer python test crash reproducibly. According to valgrind the mesh class contains quite some problematic code for the bcnames array. Typical valgrind report:
As can be seen the problematic memory block is from
Array<FaceDecoding> Mesh::facedecoding
, which has been grown (reallocated) byMesh::AddFaceDescriptor
. TheFaceDescriptor::bcname
is a member, thus growing the facedecoding array invalidates any pointers to thebcname
.Unfortunately,
Mesh::operator=(const Mesh& mesh2)
ignores this, and assigns the raw pointer&facedecoding[fi].bcname
tobcnames
:netgen/libsrc/meshing/meshclass.cpp
Lines 324 to 349 in 3bfa6c1
The text was updated successfully, but these errors were encountered: