stephenma7@hotmail.com wrote in news:1108432247.709765.250770
@c13g2000cwb.googlegroups.com:
[color=blue]
> Hi, everybody. I am new here.
>
> I have encountered these many problems for the last couple of days. I
> have Linux Fedora Core 3(Gnu G++ 3.4.2), Linux Fedora Core 2 (Gnu G++
> 3.3.3), Red Hat 9 (Gnu G++ 3.2.2, this is dual processors).
>
> I have the same set of programs that I wrote and when I ran on the
> three machines, which have different amount of memories, processors'
> speeds, and settings. I got three different seg faults at different
> places in the programs. Basically each machine would give me a seg
> fault at different points in the program codes.[/color]
Symptoms _strongly_ suggest that you've messed up your memory somewhere.
[color=blue]
> I don't think my program use up all memory that would create seg fault,
> and I don't think the errors stem from the faults that I tried to
> access memory that wasn't allocated by my program. The seg faults were
> all because of my program try to allocate memory.[/color]
Nope, you've most likely written somewhere in memory where you're not
supposed to.
[color=blue]
> Another thing is I am using gsl library, which is written in C, in my
> C++ program and this library has its own functions to allocate memory
> but at the lower system level calls it uses C malloc calls. I get seg
> faults at:
>
> 0x081096a8 in _int_malloc ()
> #1 0x08108e7b in malloc ()
> #2 0x0807962b in gsl_block_alloc (n=6) at init_source.c:39
> #3 0x08070a68 in gsl_vector_alloc (n=6) at init_source.c:40
> ------------------------------------------------------------
> 0x081185e7 in _int_malloc ()
> #1 0x08119c41 in malloc ()
> #2 0x08075222 in gsl_vector_alloc (n=2) at init_source.c:32
> #3 0x080752cd in gsl_vector_calloc (n=2) at init_source.c:64
> -----------------------------------------------------
>
> I just can not understand why I also get error relating to seg fault or
> double free memory for codes like this:
>
> void calculate21Iter(char* ctipParams, char* eamParams, int numMatrix)
> {
> double* results = NULL;
> try{
> results = new double[NITER];
> }
> catch(bad_alloc)
> {
> cerr<<"Failed to get memory for results in utility. Exit\n";
> exit(1);
> }
> int count = 0;
> for(int i = 0; i < numMatrix; i++)
> {
> for(int j = 0; j < NITER; j++)
> {
> results[count] = calculateEtot(ctipParams, count, eamParams);
> count++;
> }
>
>
> writeTDatFile(i, results);
> }
> cout<<"done 21 iter\n";
> //delete [] results;
> cout<<"just delete results\n";
> }[/color]
If numMatrix > 1, this function will write beyond the bounds of the array
named 'results'. I leave it as an exercise to the reader to see why
(hint: what is being used to index into the results array).
[color=blue]
> If i do not comment out delete [] results; I would get a double free of
> memory errors( I don't have the exact descriptions but basically it say
> I free some memory twice). If you looked at the function call
> writeTDatFile(i, results); you see i passed results there, but in that
> function I do not delete the memory. So could it be that when that
> function reach the end of execution, the results in that function is
> out of scope and then got free automatically and then in this function,
> I free it one more time.
>
> I also have a corrupted memory errors that basically happened to data
> members of a class.
> double *counts;
> Names *sysNames;
> int types;
>
> The counts and names will be allocated with new double/Names[types]
> after I read types from the file.
>
> Somehow, I ran the program and then types would become some huge
> negatives number, I f I found a way to fix types, then counts would be
> corrupted. If i fix counts, then sysNames would be corrupted. It is
> just a cycle of corrupted error among the three.
> The bad thing is I ran a total of 63 iteration over these variables and
> each time the values supposed to not change but at the same iterations
> for different variables, I would get memory corrupted. (54. types, fix
> types, 34. counts, fix counts, 45. sysNames, fix sysNames, then 54.
> types......).[/color]
Yep, you've most likely written past the end of an array.
[color=blue]
>
> All these just drive me crazy.
>
> Could somebody here give me some lights into these problems?[/color]
Yep, you're writing beyond the bounds of arrays. Probably ones which you
have dynamically allocated.
Come to think of it, in the function you posted above, what's the purpose
of dynamically allocating the array? Why not just declare it as a normal
local variable?
