Many differerent problems with seg faults.

[stephenma7]

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.

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.

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";
}

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......).

All these just drive me crazy.

Could somebody here give me some lights into these problems?

Thank you so very much.

 

[Andre Kostur]

(e-mail address removed) wrote in @c13g2000cwb.googlegroups.com:

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.

Symptoms _strongly_ suggest that you've messed up your memory somewhere.

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.

Nope, you've most likely written somewhere in memory where you're not
supposed to.

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";
}

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).

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......).

Yep, you've most likely written past the end of an array.

All these just drive me crazy.

Could somebody here give me some lights into these problems?

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?

 

[stephen7]

Thanks Andre for the tips. I couldn't believe my eyes when I looket at
the count++ withour reseting it to zero.

Yup, that is the result of pulling around 55 / hours /week at work and
some more hours at home.

I need to relax and then reexamine my codes.

Thanks Andre.

 

[Ioannis Vranos]

Thanks Andre for the tips. I couldn't believe my eyes when I looket at
the count++ withour reseting it to zero.

Yup, that is the result of pulling around 55 / hours /week at work and
some more hours at home.

I need to relax and then reexamine my codes.

I think you would benefit the most if you programmed with the more safe
and high level facilities of C++, without sacrificing efficiency,
instead of writing "assembly" with C++.


Consider your code modified:


#include <iostream>
#include <vector>
#include <cstdlib>
#include <new>
#include <string>





void calculate21Iter(const std::string &ctipParams,
const std::string &eamParams,
const int numMatrix) try
{
using namespace std;

vector<double> results(NITER);

int count = 0;

for(int i = 0; i < numMatrix; ++i)
{
for(vector<double>::size_type j = 0; j < results.size(); ++j)
{
//Can't figure out what this is supposed to do
}

writeTDatFile(i, results);
}
cout<<"done 21 iter\n";
}


catch(std::bad_alloc)
{
using namespace std;

cerr<<"Failed to get memory for results in utility. Exit\n";
exit(EXIT_FAILURE);
}

 

[Ioannis Vranos]

I think you would benefit the most if you programmed with the more safe
and high level facilities of C++, without sacrificing efficiency,
instead of writing "assembly" with C++.


Consider your code modified:


#include <iostream>
#include <vector>
#include <cstdlib>
#include <new>
#include <string>





void calculate21Iter(const std::string &ctipParams,
const std::string &eamParams,
const int numMatrix) try
{
using namespace std;

vector<double> results(NITER);

int count = 0;

for(int i = 0; i < numMatrix; ++i)
{
for(vector<double>::size_type j = 0; j < results.size(); ++j)
{
//Can't figure out what this is supposed to do
}

writeTDatFile(i, results);
}
cout<<"done 21 iter\n";
}


catch(std::bad_alloc)
{
using namespace std;

cerr<<"Failed to get memory for results in utility. Exit\n";
exit(EXIT_FAILURE);
}

And catch(std::bad_alloc) is not needed here for general applications.
In general applications, one can place one catch(std::bad_alloc) for
main() only.