Commit 5d11f62f authored by Alexis SALZMAN's avatar Alexis SALZMAN

[xFEM] add security to avoid potential memory leek in xData

One recent commit change 'mesh' data member access of class xData. It is now
a private member. Two get/set methods were added to access to this pointer.
But if we read with xData a mesh from a file and choose afterword to  use setMesh
method to reassign the 'mesh' pointer to a new mesh instance user had to
pay attention to the way he treat memory allocated done during first read from file.
If he did want to avoid potential memory leak he had to call the getMesh
method and with the return pointer free memory, all this before calling setMesh ...

This commit choose to add a state to xData to say if the 'mesh' data
member point to a memory maintained by xData or not. A new delMesh
method is then in charge of freeing memory pointed by 'mesh' pointer only if
this memory was allocated by xData. This function is called in setMesh
to avoid memory leek. It is also called in destructor to avoid to free memory
allocated by user (double free error). And it is made public to offer a
simple way to free memory allocated by xData if any.

Hop this make things more clear to user. For sure it is not ideal for
thread safety ...
parent bd464931
This diff is collapsed.
......@@ -70,12 +70,14 @@ class xData
char* GetPartFile();
xMesh* getMesh();
void setMesh(xMesh*);
void delMesh();
//
// BASIC Informations ALWAYS NEEDED
//
int Dimension; // Dimension of the problem: Derived from the mesh
private:
xMesh* mesh;
bool internal_read;
public:
xinterface::aomd::xAttachedDataManagerAOMD<int> entities_id;
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment