I am writing a class where recursion is a must when writing its constructor, then clang analyzer complains about potential memory leak of this function, although I cannot see why and can guarantee that the recursion will always terminate.
Here is the code:
VeblenNormalForm::VeblenNormalForm(CantorNormalForm* _cnf) {
terms = vnf_terms();
_is_cnf = true;
if (!_cnf->is_zero()) {
for (int i = 0; i < _cnf->terms.size(); i++) {
terms.push_back(
phi(&ZERO, new VeblenNormalForm(get<0>(_cnf->terms[i]))) * get<1>(_cnf->terms[i])
);
}
}
}
The analysis given by clang is that it tries to enter the true branch for a few times and then claims there exist a potential memory leakage. Is it a real warning or just clang analyzer doing weird things?
One problem is with exception safety. Your terms vector stores tuples of VeblenNormalForm*, which you allocate at least the second element with new.
Presumably you have corresponding deletes in your destructor, but if an exception is thrown from a constructor, the destructor will not be called.
In your case, you could allocate the first N elements correctly, but get an exception in N + 1st element. In that case, your first N elements will be leaked. terms will still get destructed properly, but since you only have raw pointers in it, nothing will be deleted properly.
You could fix this issue by making your tuple be a std::tuple<VeblenNormalForm*, std::shared_ptr<const VeblenNormalForm>>. In this case, even if you get an exception mid-construction, the smart pointers will correctly delete the well-constructed objects. This assumes the first pointer is pointing to some global variable, so it's still just a regular pointer. If that is also being dynamically allocated, you need to use a smart pointer for that as well.
Code-wise, it should look like this:
using phi = std::tuple<VeblenNormalForm*, std::shared_ptr<const VeblenNormalForm>>;
VeblenNormalForm::VeblenNormalForm(CantorNormalForm* _cnf) {
terms = vnf_terms();
_is_cnf = true;
if (!_cnf->is_zero()) {
for (int i = 0; i < _cnf->terms.size(); i++) {
terms.push_back(
phi(&ZERO, std::make_shared<VeblenNormalForm>(get<0>(_cnf->terms[i]))) * get<1>(_cnf->terms[i])
);
}
}
}
Note that these pointers point to const VeblenNormalForm. Sharing mutable data across different objects is very difficult to get right. If you can prove to yourself you will do it right, feel free to remove the const.
Related
i am currently working on a programm, where i read Information from various CAN signals and store them in 3 different vectors.
For each signal, a new pointer to an object is created an stored in two vectors.
My question is, when i am deleting the vectors, is it enough, when i delete the pointers to the objects in one vector and just clear the other one.
Here is my code:
Declaration of vectors an iterator:
std::vector <CAN_Signal*> can_signals; ///< Stores all CAN signals, found in the csv file
std::vector <CAN_Signal*> can_signals_rx; ///< Stores only the Rx CAN signals, found in the csv file
std::vector <CAN_Signal*> can_signals_tx; ///< Stores only the Tx CAN signals, found in the csv file
std::vector <CAN_Signal*>::iterator signal_iterator; ///< Iterator for iterating through the varoius vectors
Filling the vectors:
for (unsigned int i = 0; i < m_number_of_lines; ++i)
{
string s = csv_file.get_line(i);
CAN_Signal* can_signal = new CAN_Signal(s, i);
if (can_signal->read_line() == false)
return false;
can_signal->generate_data();
can_signals.push_back(can_signal);
if (get_first_character(can_signal->get_PDOName()) == 'R')
{
can_signals_rx.push_back(can_signal);
}
else if (get_first_character(can_signal->get_PDOName()) == 'T')
{
can_signals_tx.push_back(can_signal);
}
else
{
cout << "Error! Unable to detect whether signal direction is Rx or Tx!" << endl;
return false;
}
}
Deleting the vectors:
File_Output::~File_Output()
{
for (signal_iterator = can_signals.begin(); signal_iterator != can_signals.end(); ++signal_iterator)
{
delete (*signal_iterator);
}
can_signals.clear();
//for (signal_iterator = can_signals_rx.begin(); signal_iterator != can_signals_rx.end(); ++signal_iterator)
//{
// delete (*signal_iterator);
//}
can_signals_rx.clear();
//for (signal_iterator = can_signals_tx.begin(); signal_iterator != can_signals_tx.end(); ++signal_iterator)
//{
// delete (*signal_iterator);
//}
can_signals_tx.clear();
cout << "Destructor File_Output!" << endl;
}
When i uncomment the commented for-loops and run the Programm, it crashes, when the destructor is called.
So my guess is, that this is the correct way of doing so, because the pointers are allready deleted and it is enough to just clear remaining two vectors.
But i am not really sure and would really like to hear the opinion of an expert on this.
Thank you very much.
when i am deleting the vectors, is it enough, when i delete the pointers to the objects in one vector and just clear the other one.
Since the pointers in the other vectors are copies, not only is it sufficient to delete them only in the one vector, but deleting the copies would in fact have undefined behaviour. You don't ever want your program to have undefined behaviour.
Clearing any of the vectors in the destructor of File_Output seems to be unnecessary, assuming the vectors are members of File_Output. This is because the members are about to be destroyed anyway.
Am I deleting my vector of pointers to objects correctly?
With the assumption that you didn't make copies of the pointers that you delete elsewhere: Yes, that is the correct way to delete them.
Your code has a memory leak:
CAN_Signal* can_signal = new CAN_Signal(s, i);
if (can_signal->read_line() == false)
return false;
If that condition is true, then the newly allocated CAN_Signal will be leaked since the pointer is neither deleted nor stored anywhere when the function returns.
Your code is not exception safe: If any of these lines throws, then the pointer is leaked.
if (can_signal->read_line() == false)
return false;
can_signal->generate_data();
can_signals.push_back(can_signal);
It is unclear, why you would want to use explicit memory management in the first place. Unless there is a reason, I recommend that you don't do that and instead use std::vector <CAN_Signal> can_signals. This would fix your problems with memory leaks and exception safety, remove the need to implement a custom destructor, and make the implementation of copy/move constructor/assignment of File_Output simpler.
Note that if you do that, you must reserve the memory for the elements for can_signals to prevent reallocation because the pointers in other vectors would be invalidated upon reallocation. As a side-effect, this makes the program slightly faster.
The question: How to use "placement new" for creating an array with dynamic size? or more specifically, how to allocate memory for array elements from a pre-allocated memory.
I am using the following code:
void* void_array = malloc(sizeof(Int));
Int* final_array = new(void_array) Int;
This guarantees that the final_array* (the array pointer) is allocated from the place that is reserved by void_array*. But what about the final_array elements? I want them to be allocated from a pre-allocated memory as well.
P.S: I have to say that I'm using some API that gives me some controls over a tile architecture. There is a function that works exactly like malloc, but also have other features, e.g. lets you control the properties of the allocated memory. So, what i basically need to do, is to use that malloc-like function to allocate memory with my desired properties (e.g. from which memory bank, to be cached where and etc.)
First off, let's make sure we all agree on the separation of memory allocation and object construction. With that in mind, let's assume we have enough memory for an array of objects:
void * mem = std::malloc(sizeof(Foo) * N);
Now, you cannot use placement array-new, because it is broken. The correct thing to do is construct each element separately:
for (std::size_t i = 0; i != N; ++i)
{
new (static_cast<Foo*>(mem) + i) Foo;
}
(The cast is only needed for the pointer arithmetic. The actual pointer required by placement-new is just a void pointer.)
This is exactly how the standard library containers work, by the way, and how the standard library allocators are designed. The point is that you already know the number of elments, because you used it in the initial memory allocation. Therefore, you have no need for the magic provided by C++ array-new, which is all about storing the array size somewhere and calling constructors and destructors.
Destruction works in reverse:
for (std::size_t i = 0; i != N; ++i)
{
(static_cast<Foo*>(mem) + i)->~Foo();
}
std::free(mem);
One more thing you must know about, though: Exception safety. The above code is in fact not correct unless Foo has a no-throwing constructor. To code it correctly, you must also store an unwind location:
std::size_t cur = 0;
try
{
for (std::size_t i = 0; i != N; ++i, ++cur)
{
new (static_cast<Foo*>(mem) + i) Foo;
}
}
catch (...)
{
for (std::size_t i = 0; i != cur; ++i)
{
(static_cast<Foo*>(mem) + i)->~Foo();
}
throw;
}
Instead of using a custom malloc, you should overwrite operator new() and use it. This is not operator new; there is a function actually called operator new(), confusing as it may seem, which is the function used by the normal (non-placement) operator new in order to get raw memory upon which to construct objects. Of course, you only need to overwrite it if you need special memory management; otherwise the default version works fine.
The way to use it is as follows, asuming your array size will be size:
Int* final_array = static_cast<Int*>(size == 0 ? 0 : operator new(sizeof(Int) * size));
Then you can construct and destroy each element independently. For instance, for element n:
// Create
new(final_array + n) Int; // use whatever constructor you want
// Destroy
(final_array + n)->~Int();
I feel a little stupid for making a question about the deletion of pointers but I need to make sure I'm deleting in the correct way as I'm currently going through the debugging process of my program.
Basically I have a few arrays of pointers which are defined in my header file as follows:
AsteroidView *_asteroidView[16];
In a for loop I then initialise them:
for(int i = 0; i < 16; i++)
{
_asteroidView[i] = new AsteroidView();
}
Ok, so far so good, everything works fine.
When I eventually need to delete these in the destructor I use this code:
for(int i = 0; i < 16; i++)
{
delete _asteroidView[i];
}
Is this all I need to do? I feel like it is, but I'm worried about getting memory leaks.
Out of interest...
Is there much of a difference between an Array of Points to Objects compared with an Array of Objects?
This is correct. However, you may want to consider using Boost.PointerContainer, and save you hassle the hassle of manual resource management:
boost::ptr_vector<AsteroidView> _asteroidView;
for(int i = 0; i < 16; i++)
{
_asteroidView.push_back(new AsteroidView());
}
You do not have to manage the deletion, the container does that for you. This technique is called RAII, and you should learn about it if you want to have fun using C++ :)
About your edit: There are several difference, but I guess the most important are these:
An array of pointers can contain objects of different types, if these are subclasses of the array type.
An array of objects does not need any deletion, all objects are destroyed when the array is destroyed.
It's absolutely fine.
The rule of thumb is: match each call to new with an appropriate call to delete (and each call to new[] with a call to delete[])
Is this all I need to do? I feel like it is, but I'm worried about getting memory leaks.
Yes. The program is deallocating resources correctly. No memory leaks :)
If you are comfortable with using std::vector( infact it is easy ), it does the deallocation process when it goes out of scope. However, the type should be of -
std::vector<AsteroidView>
Given a class:
// this class has hidden data and no methods other than the constructor/destructor
// obviously it's not ready for prime time
class Foo {
int* bar_[16];
public:
Foo()
{
for (unsigned int i = 0; i < 16; ++i)
bar_[i] = new int;
}
~Foo()
{
for (unsigned int i= 0; i < 16; ++i)
delete bar_[i];
}
};
You won't leak memory if the constructor completes correctly. However, if new fails fails in the constructor (new throws a std::bad_alloc if you're out of memory), then the destructor is not run, and you will have a memory leak. If that bothers you, you will have to make the constructor exception safe (say, add a try ... catch block around the constructor, use RAII). Personally, I would just use the Boost Pointer Container if the elements in the array must be pointers, and a std::vector if not.
TL;DR
Boost-Test-Framework crashes with no error given while passing all tests and leaking all memory.
Test fails multiple times with mentioned destructor implementations. Clear function also throws heap error.
What are we doing wrong with the dtor?
TL;DR
This is pertaining to a college homework assignment, and my friend's solution to said problem. In order to get more aquainted with C-style pointers and a more low-level style of programming, we needed to implement our own dynamic array.
His assignment is complete and completely functional according to our teacher's 900-LOC Boost-Test Framework. The only problem is the crash (or heap error, as no real error message pops up) when the tests exit, or an implemented dtor is called.
His dynamic array uses three pointers: pFirst, pLast and pEnd, pointing to the first element of the array, to the one past the last element in the array, and pointing to the last not-yet allocated element in the array respectively.
His program passed as long as he didn't try to delete any pointers. This is a bad idea, but hey, it let him pass the assignment. For now.
My friend has tried several times to implement a destructor, but they both cause heap errors and cause the test-framework to fail.
// Teacher's recommended dtor.
Field::~Field()
{
for(int i(0); i != this->size(); ++i)
(pFirst+i)->~T();
delete pFirst;
pFirst = pLast = pEnd = NULL;
}
and
// My recommendation to friend.
Field::~Field()
{
delete[] pFirst;
pFirst = pLast = pEnd = NULL;
}
both crash with the same heap error.
Assertion failed: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
A typical chain of tests looks like:
BOOST_AUTO_TEST_CASE( TEST_clear )
{
Field f( 3, 4.0f );
f.clear(); // Error here IF we use delete in the clear method.
BOOST_CHECK( f.size()==0 );
BOOST_CHECK( f.capacity()==4 );
} // Error here; during destruction IF we have implemented the dtor.
The clear method emits the same error when we try to replace the array, so we just have:
void Field::clear()
{
size_t capa = capacity();
T *temp =pFirst;
pFirst = new T[capa];
pLast = pFirst;
pEnd = pFirst+capa;
}
What are we doing wrong with the dtor, clear and in general when dealing with the deletion of pointers?
Assertion failed: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) indicates heap corruption. Usually it happens when you write past the end of the allocated memory.
I see the following issue in your code: in Field::clear you store the pointer to allocated memory in pFirst and immediately overwrite it by pLast. I think you should change it to pLast = pFirst;.
Teacher's recommended dtor makes no sense to me. If you allocate with new[] then deallocate with delete[], don't call each destructor separately and use delete.
If pFirst points to the first element of the array, then your "teacher's recommended dtor" is wrong. You'd need to say delete[] pFirst to deallocate the array.
But there are many issues which could be causing this, such as heap corruption caused by some other function. Try running this in a memory-corruption check program, like Valgrind, to see if you are overflowing your heap buffer.
I am observing strange behaviour of std::map::clear(). This method is supposed to call element's destructor when called, however memory is still accessible after call to clear().
For example:
struct A
{
~A() { x = 0; }
int x;
};
int main( void )
{
std::map< int, A * > my_map;
A *a = new A();
a->x = 5;
my_map.insert( std::make_pair< int, *A >( 0, a ) );
// addresses will be the same, will print 5
std::cout << a << " " << my_map[0] << " " << my_map[0]->x << std::endl;
my_map.clear();
// will be 0
std::cout << a->x << std::endl;
return 0;
}
The question is, why is variable a still accessible after its destructor was called by map::clear()? Do I need to write delete a; after calling my_map.clear() or is it safe to overwrite the contents of a?
Thanks in advance for your help,
sneg
If you store pointers on a map (or a list, or anything like that) YOU are the responsible for deleting the pointers, since the map doesn't know if they have been created with new, or not. The clear function only invokes destructors if you don't use pointers.
Oh, and one more thing: invoking a destructor (or even calling delete) doesn't mean the memory can't be accessed anymore. It only means that you will be accessing garbage if you do.
std::map does not manage the memory pointed to by the pointer values - it's up to you to do it yourself. If you don't want to use smart pointers, you can write a general purpose free & clear function like this:
template <typename M> void FreeClear( M & amap )
for ( typename M::iterator it = amap.begin(); it != amap.end(); ++it ) {
delete it->second;
}
amap.clear();
}
And use it:
std::map< int, A * > my_map;
// populate
FreeClear( my_map )
;
That's because map.clear() calls destructors of the data contained in the map, in your case, of the pointer to a. And this does nothing.
You might want to put some kind of smart pointer in the map for the memory occupied by a to be automatically reclaimed.
BTW, why do you put the template arguments in the call to make_pair? The template argument deduction should do pretty well here.
When you free a piece of heap memory, its contents don't get zeroed. They are merely available for allocation again. Of course you should consider the memory non accessible, because the effects of accessing unallocated memory are undefined.
Actually preventing access to a memory page happens on a lower level, and std libraries don't do that.
When you allocate memory with new, you need to delete it yourself, unless you use a smart pointer.
Any container stores your object Type and call corresponding constructors: internal code each node might look similar to:
__NodePtr
{
*next;
__Ty Val;
}
When you allocate it happens by constructing the val based on type and then linking. Something similar to:
_Ty _Val = _Ty();
_Myhead = _Buynode();
_Construct_n(_Count, _Val);
When you delete it calls corresponding destructors.
When you store references (pointers) it won't call any constructor nor it will destruct.
Having spent the last 2 months eating, sleeping, and breathing maps, I have a recommendation. Let the map allocate it's own data whenever possible. It's a lot cleaner, for exactly the kind of reasons you're highlighting here.
There are also some subtle advantages, like if you're copying data from a file or socket to the map's data, the data storage exists as soon as the node exists because when the map calls malloc() to allocate the node, it allocates memory for both the key and the data. (AKA map[key].first and map[key].second)
This allows you to use the assignment operator instead of memcpy(), and requires 1 less call to malloc() - the one you make.
IC_CDR CDR, *pThisCDRLeafData; // a large struct{}
while(1 == fread(CDR, sizeof(CDR), 1, fp)) {
if(feof(fp)) {
printf("\nfread() failure in %s at line %i", __FILE__, __LINE__);
}
cdrMap[CDR.iGUID] = CDR; // no need for a malloc() and memcpy() here
pThisCDRLeafData = &cdrMap[CDR.iGUID]; // pointer to tree node's data
A few caveats to be aware of are worth pointing out here.
do NOT call malloc() or new in the line of code that adds the tree node as your call to malloc() will return a pointer BEFORE the map's call to malloc() has allocated a place to hold the return from your malloc().
in Debug mode, expect to have similar problems when trying to free() your memory. Both of these seem like compiler problems to me, but at least in MSVC 2012, they exist and are a serious problem.
give some thought as to where to "anchor" your maps. IE: where they are declared. You don't want them going out of scope by mistake. main{} is always safe.
INT _tmain(INT argc, char* argv[]) {
IC_CDR CDR, *pThisCDRLeafData=NULL;
CDR_MAP cdrMap;
CUST_MAP custMap;
KCI_MAP kciMap;
I've had very good luck, and am very happy having a critical map allocate a structure as it's node data, and having that struct "anchor" a map. While anonymous structs have been abandoned by C++ (a horrible, horrible decision that MUST be reversed), maps that are the 1st struct member work just like anonymous structs. Very slick and clean with zero size-effects. Passing a pointer to the leaf-owned struct, or a copy of the struct by value in a function call, both work very nicely. Highly recommended.
you can trap the return values for .insert to determine if it found an existing node on that key, or created a new one. (see #12 for code) Using the subscript notation doesn't allow this. It might be better to settle on .insert and stick with it, especially because the [] notation doesn't work with multimaps. (it would make no sense to do so, as there isn't "a" key, but a series of keys with the same values in a multimap)
you can, and should, also trap returns for .erase and .empty() (YES, it's annoying that some of these things are functions, and need the () and some, like .erase, don't)
you can get both the key value and the data value for any map node using .first and .second, which all maps, by convention, use to return the key and data respectively
save yourself a HUGE amount of confusion and typing, and use typedefs for your maps, like so.
typedef map<ULLNG, IC_CDR> CDR_MAP;
typedef map<ULLNG, pIC_CDR> CALL_MAP;
typedef struct {
CALL_MAP callMap;
ULNG Knt;
DBL BurnRateSec;
DBL DeciCents;
ULLNG tThen;
DBL OldKCIKey;
} CUST_SUM, *pCUST_SUM;
typedef map<ULNG,CUST_SUM> CUST_MAP, CUST_MAP;
typedef map<DBL,pCUST_SUM> KCI_MAP;
pass references to maps using the typedef and & operator as in
ULNG DestroyCustomer_callMap(CUST_SUM Summary, CDR_MAP& cdrMap, KCI_MAP& kciMap)
use the "auto" variable type for iterators. The compiler will figure out from the type specified in the rest of the for() loop body what kind of map typedef to use. It's so clean it's almost magic!
for(auto itr = Summary.callMap.begin(); itr!= Summary.callMap.end(); ++itr) {
define some manifest constants to make the return from .erase and .empty() more meaningfull.
if(ERASE_SUCCESSFUL == cdrMap.erase (itr->second->iGUID)) {
given that "smart pointers" are really just keeping a reference count, remember you can always keep your own reference count, an probably in a cleaner, and more obvious way. Combining this with #5 and #10 above, you can write some nice clean code like this.
#define Pear(x,y) std::make_pair(x,y) // some macro magic
auto res = pSumStruct->callMap.insert(Pear(pCDR->iGUID,pCDR));
if ( ! res.second ) {
pCDR->RefKnt=2;
} else {
pCDR->RefKnt=1;
pSumStruct->Knt += 1;
}
using a pointer to hang onto a map node which allocates everything for itself, IE: no user pointers pointing to user malloc()ed objects, works well, is potentially more efficient, and and be used to mutate a node's data without side-effects in my experience.
on the same theme, such a pointer can be used very effectively to preserve the state of a node, as in pThisCDRLeafData above. Passing this to a function that mutates/changes that particular node's data is cleaner than passing a reference to the map and the key needed to get back to the node pThisCDRLeafData is pointing to.
iterators are not magic. They are expensive and slow, as you are navigating the map to get values. For a map holding a million values, you can read a node based on a key at about 20 million per second. With iterators it's probably ~ 1000 times as slow.
I think that about covers it for now. Will update if any of this changes or there's additional insights to share. I am especially enjoying using the STL with C code. IE: not a class in sight anywhere. They just don't make sense in the context I'm working in, and it's not an issue. Good luck.