Error in vector array deallocation after subroutine completion

Apologies if this isn't a beginner question
I have a crashing subroutine with a linux ubuntu environment
When called it makes a number and then declares two equally sized int vector arrays with it
It then takes a picture array and uses two for loops to read it, one to read x pixels and one for y pixels, for each value read depending on the value one of the members of the vector arrays gets +1
At the end of each x-pixel for loop the results of the first arrays are read into the second vector array via use of a for loop, this continues for every y value of x values
At the end of the y-loop the second vector array is wrote into a csv file
At this point the subroutine is over and the program goes back at which point it crashes with a 'Double free or corruption (out)' message
Through googling what I know is this is some sort of pointer problem, something is being read or deleted twice or whatever when it exits, problem is the code I'm using to make these vectors is the code recommended to prevent that sort of problem so I have no clue

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#include <iostream>
#include <fstream>
#include <sstream>
#include <stdlib.h>
#include <math.h>
#include <vector>
using namespace std;

/**************************************/
void Histogram(comp a)
{
  float x; /*value from reading pixels*/
  const double striplength=0.05; /*set interval length*/
  int numbuck=(int)ceil(8/striplength); /*set number of histogram receptors*/
  std::vector<int> histogram(numbuck); /*set initial histogram*/
  std::vector<int> histogramend(numbuck);  /*set histogram that will trigger for y-pixels*/
/*these vectors are the problem somehow I'm pretty sure*/
  for(int x1=0; x1<1024; x1++)
  { /*imp2*/
  for(int y1=0; y1<1024; y1++){ /*imp*/
  x=a.getvalue(x1,y1);
  if (x==0){ /* a1 */    /*avoid empty pixels*/
   histogram[1]=histogram[1];
  } /* a1 */
  else{ /* a2 */
     int bucket=(int)floor(x/striplength);
     histogram[bucket]+=1; /*for every x pixel add to the histogram if the value falls between the value predetermined*/
  } /* a2 */
} /*imp*/

for(int x2=0; x2<histogram.size(); x2++){
histogramend[x2]=histogramend[x2]+histogram[x2]; /*for every y-pixel add the x histograms together*/
}
} /* imp2 */
  ofstream mfile;
  cout << "About to open file" <<endl;
  mfile.open("histogram.csv", ios::out | ios::app); /*output to a file, this is looped so I use this to avoid my data being overwritten*/
  for(int x3=0; x3<histogram.size(); x3++){
  mfile << histogramend[x3] << ",";
  }
  mfile.close();
  cout << "Closed file" <<endl;
cout << "About to leave" <<endl; /*figure out where its going wrong */
}
Can't see anything blatantly obvious, but this is only a fragment of code.
Why don't you write out x1 and y1 after line 20 to see where exactly your code crashes.
Similarly in the other loops.
You need to track at precisely which point it crashed.


Other comments:-
- Use the C++ headers (cstdlib, not stdlib.h; cmath, not math.h)
- line 23 doesn't do anything!
- unless vectors automatically initialise (I don't know!) how do you know that every element of histogram and histogramend is actually defined with a value?
void Histogram(comp a)

What is the input parameter comp a? Is this a user-defined type, or from some library?
Have solved it, thank you for helping in Eureka moment
Problem was that a.getvalue was getting negative numbers, then those negative numbers were being used to assign values to negative members of the vector array that didn't exist
I have no clue as to the technical details but when the subroutine exited was when those negative members of the vector array that weren't assigned beforehand caught up and caused a crash, just need to add an offset to prevent negative numbers
@lastchance
line 23 was supposed to not do anything, didn't want zeros being recorded in case of getting a zero
@Chervil
comp a was a user defined type
Thanks for the reply. As you found a solution, that's ok. I did wonder whether that user-defined type had its own memory allocation issues. No need to look at that now.
Topic archived. No new replies allowed.