EDIT: Thanks a lot for the answers. That's right, I will try using vectors instead.
I have a program where I dynamically allocate memory.
The class has an attribute which is an array of structs (**) and also an array of pointers (*) which point to each element of the array of structs, so I make 2 Mallocs. The struct is called "context".
The realloc works fine and doesn't return NULL, but as soon as I have more than 2 elements, the program will give me a segfault when trying to save a value in an element of the array. How can I prevent this segfault?
int my_class::method(uint32_t struct_element)
{
int i= this->numofcontexts;
if(this->local_context_array == NULL)
// That means it is empty and we have to make our first malloc
{
this->local_context_array = (context_t**) malloc(sizeof(context_t*));
*(this->local_context_array) = (context_t*) malloc(sizeof(context_t));
i++;
std::cout << "\n1 Malloc was made of size " << sizeof(context_t)<<"\n";
}
else
// Array is not empty and we have to use realloc
{
this->local_context_array = (context_t**) realloc(this->local_context_array, (i+1)*sizeof(context_t*));
*(this->local_context_array) = (context_t*) realloc(*(this->local_context_array), (i+1)*(sizeof(context_t)));
std::cout << "\n1 Realloc was made of size " << (i+1)*(sizeof(context_t)) <<"\n";
i++;
std::cout << "\nWe now have " << i <<" elements\n";
// As soon as the array is bigger than 2 elements, this gives segmentation fault:
//(this->local_context_array[i-1])->struct_element = struct_element;
}
From the code posted and the symptoms you describe, it seems you do not do this at the end:
this->numofcontexts = i;
If this is true, then every time you call this method, it will find numofcontexts == 0 and local_context_array not NULL, so it will move to your else clause, when it will reallocate the array to i+1 (always 1).
First call will succeed, second call will also succeed with array size of 1 element, and if you try to assign to elements over [0] at this point, you may get a segfault. The reason you might not get a segfault at [1] is usually related to some other variable occupying the space and being trashed but which does not always generate a segfault immediately.
Related
Apologies if my question does not contain all relevant info. Please comment and I will amend accordingly.
I use CLion on Win7 with MinGW and gcc
I have been experimenting with circular buffers and came across boost::circular_buffer, but for the size of my project I want to use circular buffer by Pete Goodlife, which seems like a solid implementation in just one .hpp.
Note: I am aware of how to reduce boost dependecies thanks to Boost dependencies and bcp.
However, the following example with Pete's implementation does not behave as expected, i.e. the result to std::adjacent_difference(cbuf.begin(),cbuf.end(),df.begin()); comes out empty. I would like to understand why and possibly correct its behaviour.
Follows a MWE:
#include "circular.h"
#include <iostream>
#include <algorithm>
typedef circular_buffer<int> cbuf_type;
void print_cbuf_contents(cbuf_type &cbuf){
std::cout << "Printing cbuf size("
<<cbuf.size()<<"/"<<cbuf.capacity()<<") contents...\n";
for (size_t n = 0; n < cbuf.size(); ++n)
std::cout << " " << n << ": " << cbuf[n] << "\n";
if (!cbuf.empty()) {
std::cout << " front()=" << cbuf.front()
<< ", back()=" << cbuf.back() << "\n";
} else {
std::cout << " empty\n";
}
}
int main()
{
cbuf_type cbuf(5);
for (int n = 0; n < 3; ++n) cbuf.push_back(n);
print_cbuf_contents(cbuf);
cbuf_type df(5);
std::adjacent_difference(cbuf.begin(),cbuf.end(),df.begin());
print_cbuf_contents(df);
}
Which prints the following:
Printing cbuf size(3/5) contents...
0: 0
1: 1
2: 2
front()=0, back()=2
Printing cbuf size(0/5) contents...
empty
Unfortunately, being new to c++ I can’t figure out why the df.begin() iterator is not dereferenced as an lvalue.
I supsect the culprit is (or don't completely uderstand) the member call of the circular_buffer_iterator on line 72 in Pete's circular.h:
elem_type &operator*() { return (*buf_)[pos_]; }
Any help is very much appreciated.
The iterator you pass as the output iterator is dereferenced and treated as an lvalue, and most probably the data you expect is actually stored in the circular buffer's buffer.
The problem is, that apart from the actual storage buffer, most containers also contain some internal book-keeping state that has to be maintained. (for instance: how many elements is in the buffer, how much frees space is left etc).
Dereferencing and incrementing the container doesn't update the internal state, so the container does not "know" that new data has been added.
Consider the following code:
std::vector<int> v;
v.reserve(3);
auto i = v.begin();
*(i++) = 1; // this simply writes to memory
*(i++) = 2; // but doesn't update the internal
*(i++) = 3; // state of the vector
assert(v.size() == 0); // so the vector still "thinks" it's empty
Using push_back would work as expected:
std::vector<int> v;
v.reserve(3);
v.push_back(1); // adds to the storage AND updates internal state
v.push_back(2);
v.push_back(3);
assert(v.size() == 3); // so the vector "knows" it has 3 elements
In your case, you should use std::back_inserter, an iterator that calls "push_back" on a container every time it is dereferenced:
std::adjacent_difference(
cbuf.begin(), cbuf.end(),
std::back_inserter(df));
std::adjacent_difference writes to the result iterator. In your case, that result iterator points into df, which has a size of 0 and a capacity of 5. Those writes will be into the reserved memory of df, but will not change the size of the container, so size will still be 0, and the first 3 ints of the reserved container space will have your difference. In order to see the results, the container being written into must already have data stored in the slots being written to.
So to see the results you must put data into the circular buffer before the difference, then resize the container to the appropriate size (based in the iterator returned by adjacent_difference.
I have a short clip of C++ code that should theoretically work to create and return a torch.IntTensor object, but when I call it from Torch I get garbage data.
Here is my code (note this snippet leaves out the function registering, but suffice it to say that it registers fine--I can provide it if necessary):
static int ltest(lua_State* L)
{
std::vector<int> matches;
for (int i = 0; i < 10; i++)
{
matches.push_back(i);
}
performMatching(dist, matches, ratio_threshold);
THIntStorage* storage = THIntStorage_newWithData(&matches[0], matches.size());
THIntTensor* tensorMatches = THIntTensor_newWithStorage1d(storage, 0, matches.size(), 1);
// Push result to Lua stack
luaT_pushudata(L, (void*)tensorMatches, "torch.IntTensor");
return 1;
}
When I call this from Lua, I should get a [torch.IntTensor of size 10] and I do. However, the data appears to be either memory addresses or junk:
29677072
0
16712197
3
0
0
29677328
0
4387616
0
[torch.IntTensor of size 10]
It should have been the numbers [0,9].
Where am I going wrong?
For the record, when I test it in C++
for (int i = 0; i < storage->size; i++)
std::cout << *(storage->data+i) << std::endl;
prints the proper values.
As does
for (int i = 0; i < tensorMatches->storage->size; i++)
std::cout << *(tensorMatches->storage->data+i) << std::endl;
so it seems clear to me that the problem lies in the exchange between C++ and Lua.
So I got an answer elsewhere--the Google group for Torch7--but I'll copy and paste it here for anyone who may need it.
From user #alban desmaison:
Your problem is actually memory management.
When your C++ function return, you vector<int> is free, and so is its content.
From that point onward, the tensor is pointing to free memory and when you access it, you access freed memory.
You will have to either:
Allocate memory on the heap with malloc (as an array of ints) and use THIntStorage_newWithData as you currently do (the pointer that you give to newWithData will be freeed when it is not used anymore by Torch).
Use a vector<int> the way you currently do but create a new Tensor with a given size with THIntTensor_newWithSize1d(matches.size()) and then copy the content of the vector into the tensor.
For the record, I couldn't get it to work with malloc but the copying memory approach worked just fine.
In my attempt to load .OBJ-files I load vertex data into std::vectors to send them to the GPU later. I fill three vectors, for normals, vertices and texture coordinates. The size of the normal vector is far higher than the size of the other two vectors, even if its filled with the same number of elements.
Code:
SceneTree* generateSceneTree(OBJScene* scene){
PostProcessing::triangulateFaces(scene);
SceneNode* node = new SceneNode;
vector<Vec<3>>& sceneNormals = scene->attributeData[Attribute::Normal];
vector<Vec<3>>& sceneVertices = scene->attributeData[Attribute::Position];
vector<Vec<3>>& sceneTexCoords = scene->attributeData[Attribute::TexCoord];
map<string,MaterialInfo*> mtls;
for(string s : scene->mtlLibs){
auto temp = loadMTL(s);
mtls.insert(temp.begin(),temp.end());
}
vector<Vec<3>> meshNormals; <-- creating vectors here.
vector<Vec<3>> meshVertices;
vector<Vec<2>> meshTexCoords;
for(auto g : scene->groups){
meshNormals.clear();
meshNormals.reserve(g.faces.size()*3);
meshVertices.clear();
meshVertices.reserve(g.faces.size()*3);
meshTexCoords.clear();
meshTexCoords.reserve(g.faces.size()*3);
AABB bBox;
cout << "num of faces: " << g.faces.size() << endl;
for(auto f : g.faces){
for(auto p : f.points){
uint vIndex = p.indices[Attribute::Position];
uint nIndex = p.indices[Attribute::Normal];
uint tIndex = p.indices[Attribute::TexCoord];
Vec<3> n = sceneNormals.at(nIndex);
Vec<3> v = sceneVertices.at(vIndex);
Vec<3> t = sceneTexCoords.at(tIndex);
meshNormals.push_back(n);
meshVertices.push_back(v);
meshTexCoords.push_back(t.toVec<2>());
bBox += meshVertices.back();
}
}
cout << "meshNormals size: " << meshNormals.size() << endl;
cout << "meshVertices size: " << meshVertices.size() << endl;
cout << "meshTexCoords size: " << meshTexCoords.size() << endl;
Mesh* m = new Mesh({
{meshVertices,Attribute::Position},
{meshNormals,Attribute::Normal},
{meshTexCoords,Attribute::TexCoord}
},GL_TRIANGLES);
SceneLeaf* leaf = new SceneLeaf;
leaf->nodeData = {Matrix4(),bBox};
leaf->leafData = {m, mtls[g.mtlName]};
node->addChild(leaf);
}
return node;
}
Output:
num of faces: 1087474
meshNormals size: 2958875950
meshVertices size: 3262422
meshTexCoords size: 3262422
This seems highly illogical. The program crashs afterwards with a std::bad_array_new_length exception because the Mesh class cant create an array of size 2958875950 to send to the GPU.
Update:
If I swap the declarations of meshVertices and meshNormals, meshVertices has the wrong size. So the first created vector is affected.
If I use std::list instead of std::vector, everything works.
If I comment out the ....reserve(g.faces.size()*3); lines, a std::bad_alloc is thrown.
My guess is that you have a memory corruption bug "somewhere" that is overwriting the meshNormals variable on the stack. The fact that swapping the meshNormals and meshVertices declarations leads to meshVertices becoming bad matches that theory.
To narrow in on the problem you can do a few things:
Comment out all lines in the inner for(auto p : f.points) loop and see if the error still occurs.
Assuming it doesn't, start uncommenting lines one-by-one until the error shows up again.
Try making a minimal, stand-alone test code example that duplicates the problem (it would help immensely if you did this before posting a SO question).
The simple answer is that your pointers at the start are pointing to somewhere else, either:
You are casting the "scene" structure.
You have junk or unset pointer in the scene structure for normal vector. Could be that you put junk there far before entring the function.
You did notice the 2958875950 is junk/negative integer?
I was messing around trying to understand pointers and the operator "new"
and I ended up getting even more confused on what these 2 codes should result to, which is other but its not, so I wanted to understand what happened here.
thanks in advance.
#include <iostream>
using namespace std;
int main()
{
int * p = new int(50);
p[1] = 33;
cout << *p << endl;
}
Output: 50
and when I tried this
#include <iostream>
using namespace std;
int main()
{
int * p = new int[50];
p[1] = 33;
cout << *p << endl;
}
Output: -842150451
I was wondering about the meaning of each result.
In the first case
int * p = new int(50); // allocates 1 int on heap, initialized to value of 50
p[ 1] = 33; // p gives you the address of integer,
// p[1] moves the p pointer forward and accessing
// the pointed object results in undefined behavior,
// this means that at this moment anything can happen
// exception, crash, home war, nothing, everything,
// printing garbage value as well
In the second case:
int* p = new int[50]; // allocates 50 ints on heap, uninitialized
p[ 1] = 17; // initializes element with index 1 to value of 17
std::cout << *p; // p gives you the address of first element, with index 0
// which is still uninitialized, thus prints garbages
You should use
int* p = new int[50]();
to value-initialize ints to 0.
In the first one, you created dynamically a single int with a value of 50. When you try to assign the value 33, you actually assign it in memory that is not yours. It is undefined behaviour. But when you print it, you print the original value you made, which was 50.
In the second one, you created dynamically an array of 50 int. You've then specified the second value of in the array should be 33.* So when you print the value with cout << *p << endl;, you end up printing only the first value, which is undefined. Try it again, you'll probably get another value.
*Edit: as pointed in the comments, I should have been more explicit about this. An array starts at 0. So if you want to access the first value p[0] would do it.
In the first case you're creating an array of 50 ints, assigning a value to the SECOND int in the array, and then printing the first element in the array. Array indices start at 0, so when you dereference the pointer in your cout statement, it's printing whatever happened to be in memory at index 0.
In the second case you're creating a single integer, and initializing it with the value 50. When you dereference the pointer in the print statement, you're getting the integer you just created. The p[1] = 33 may or may not cause an error as your accessing unassigned memory.
int* p = new int[50];
allocates an array of int on the heap with 50 uninitialized elements, ranging from index 0 to 49.
Setting p[1] to 33 doesn't change p[0] which is what you're printing with "cout << *p".
The value -842150451 (0xCDCDCDCD in hex) is a magic number "Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory", see this question on SO.
int* p = new int(50);
allocates exactly one int on the heap and initializes it with the value 50, so setting p[1] afterwards should result in undefined behavior since you didn't allocate that memory where p[1] is referring to.
I'd recommend to use the Visual Studio Memory Windows to see what happens to the memory you're allocating while stepping through your code.
EDIT: Pastebin links to the entirety of the code at the bottom
for my CS215 course, I was given a class called String215 which is a basic string class to help in the understanding of dynamic memory allocation and pointer arithmetic with char arrays.
The class was given to me in a very basic skeleton form with prototypes but no implementations, along with a test function to test my implementations. I CAN NOT use any C String functions in this assignment.
The part of the program which is troubling is the append function, which just appends a parameter string215 object to the end of the current string215 object.
// Add a suffix to the end of this string. Allocates and frees memory.
void string215::append(const string215 &suffix)
{
char *output = new char[str_len(data)+suffix.length()+1];
for(int x = 0; x < str_len(data); x++) {
*output = *data;
output++;
data++;
}
for(int x = 0; x < suffix.length(); x++) {
*output = suffix.getchar(x);
output++;
}
*output = '\0';
output -= (str_len(data)+suffix.length()+1);
delete[] data;
data = output;
}
This portion of the code is tested in the 13th test of the test function as shown here:
string215 str("testing");
...
// Test 13: test that append works in a simple case.
curr_test++;
string215 suffix("123");
str.append(suffix);
if (strcmp(str.c_str(), "testing123") != 0) {
cerr << "Test " << curr_test << " failed." << endl;
failed++;
}
Here is the description of the append class:
Add the suffix to the end of this string. Allocates a new, larger, array; copies the old contents, followed by the suffix, to the new array; then frees the old array and updates the pointer to the new one.
My program aborts at the very end of the append function execution with the error message:
Debug Assertion Failed!
Program: [Source path]\dbgdel.cpp
Line: 52
Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
...
Abort || Retry || Ignore
I'm fairly certain it has something to do with my very poor memory management. I know it's not a lot to go on, but I've been struggling with this for hours on end and can't seem to figure it out.
Here's a pastebin of the .cpp and .h file for this program
string215.cpp: http://pastebin.com/Xh2SvDKJ
string215.h: http://pastebin.com/JfAJDEVN
Any help at all is greatly appreciated!
Thanks,
RAW-BERRY
You are changing data pointer before delete[]. You need to delete[] exactly the same value you got from new[].
Also, you are incrementing output pointer str_len(data)+suffix.length() times, and you take it back by str_len(data) + suffix.length() + 1.
I would use separate variables for iteration to solve these problems.
You increment output exactly str_len(data) + suffix.length() times. Note that you don't increment output after *output = '\0';.
So to go back to the start, you should use:
output -= (str_len(data) + suffix.length());
By the way, some of the code is not very efficient. For example, getchar uses a loop instead of simply returning data[index]. You use getchar in append, which means that the performance isn't great.
EDIT: As zch says, you use delete[] data after modifying data, but note that even before that you use str_len(data) after modifying data (when deciding how many bytes to go skip back), so the calculation is wrong (and my suggestion above is also wrong, because str_len(data) is now zero).
So I think your problem is with the line
for(int x = 0; x < str_len(data); x++) {
Notice that the size of 'data' is changing at each iteration of the loop. As you increment 'x', you are decreasing the length of 'data'. Suppose 'data' is a string holding "hello": in the first iteration of the loop x=0 and str_len(data)=5; in the second iteration x=1 and str_len(data)=4. Thus the for loop executes half as many times as you need it to and 'data' does not end up pointing to the end of the data string