I am using Dev-C++ 4.9.9.2 on a Dell PC using Windows XP and Pentium 4.
I have had this problem for a couple of days. I run the program, and it crashes. I try to use the debugger to find out why(and where) I have a problem, and the program runs fine - no errors.
When it crashes I see:
Project_track_seed_r.exe - Application Error
with a red circle with a white x with:
The instruction at "0x77f580db" referenced memory at "0x00000000". The memory could not be "written".
Click on OK to terminate the program
Click on CANCEL to debuf the program
with OK and Cancel boxes.
When I run the debug it will run right thru this section and immediately print the 2nd cout also.
Same situation yesterday, the only difference was the error message was different, but the regular run crashes and the debugger runs right thru this section with no problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
please provide a downstripped sample of your source code that shows the same behaviour, otherwise it is basically impossible to tell where exactly you fail to do your memory allocation properly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are pat->first_name and pat->last_name C-style strings? Then you may have not allocated memory for them before the getline() calls.
I agree with the first answer, you could show us the declarations of your variables and how you initialize them. Also you can do a cout after each line, so you can tell us more precisely which line causes problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
int meet_ath_ID_num;
string team_abbr;
string last_name, first_name;
int grade;
string seed_com, run_com;
};
class Athlete : public Indvid
{
// protected:
public:
int num_of_ath_events;
static Athlete* pHead_ath;
static Athlete* pTail_ath;
Athlete* pNext_ath;
Athlete* pPrev_ath;
Athlete* pNext_ath_by_team;
Athlete* pPrev_ath_by_team;
int ath;
W_trials *pAth_ev_wt[3];
Run *pAth_ev_r[5];
Field *pAth_ev_f[5];
int ath_ev[17];
friend class Meet_info;
public:
Athlete();
int name_ath();
int add_events();
int athletes_and_addresses();
int go_to_athlete(int);
};
extern Athlete pat;
extern Athlete Pt_ath[];
When I put in the couts, the crash happens after the getline last_name - apparently with the getline first_name.
Here is the start of the textfile copied and pasted:
3
Bixler
Travis
9
0
1
1
1
I appreciate the effort to help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What exactly do you think/hope/intend to do with that statement? Do you actually do any additional initialization later on in your source code?
And apart from that:
1) please provide a self-contained (and minimal )piece of source code (i.e that compiles) that shows the same behaviour
2) your variables don't seem to be named intuitively, if you cannot change the variable names, please consider commenting the purpose of each variable
3) commenting your sources in general, would be an awesome idea as it can significantly simplify the process of enabling other people to understand (the intentions that made you write) your source code
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You need to understand, that good source code shouldn't require an extraordinary amount of time to understand it, even if you haven't written it yourself-people should be able to understand it fairly quickly. Picking proper variable names, as well as adding useful comments can be tremendously helpful. In particular, if you are new to programming, there's hardly anything wrong with commenting "too much", simply because it will enable other people to understand what you are trying to do with your source code, in plain English.
Another thing you might take into consideration, would be to replace constants with preprocessor macros or even global constant variables using telling names, so that people will be able to understand these constants immediatley.
Also, I am just about to actually understand the naming of your variables, and would advise you to either follow more established naming conventions or simply use plain English instead of the hybrid mix that you currently employ, simply because it creates additional complexity.
For example:if you name one class "Athlete", why don't you simply name the parent class "Individual" rather than only "Indvid", which leaves room for guessing? Likewise, you seem to be somewhat ambivalent concerning the naming of your pointer variables (using once prefix "pt_" and then only "p").
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am including the whole function:
I put *** where the problem exists. Test 2 and test3 print and then crashes when executing. But when I use the debugger, there is no problem.
// function - retrieve the athletes for a meet
int Meet_team::retrieve_team_athletes(string code, Meet_team pmt)
{
int i = 0, j;
Athlete pat2;
string file_name = code + "ath" + pmt->team_abbr;
// cout << "\nThe textfile name * 17 * is "<<file_name << endl;
file_name_txt(file_name);
// cout << "\nThe textfile name * 27 * is "<<file_name << endl;
ifstream fin;
fin.open (file_name.c_str());
if(!fin.good())
{
cout<<"Error finding "<<file_name<<endl;
return 1;
}
while (!fin.eof() )
{
i++;
cout << i << endl;
pat = new Athlete;
cout << "\n" << i << " " << pat << endl;
fin >> pat->meet_ath_ID_num >> ws;
pat->team_abbr = pmt->team_abbr;
cout <<"\ni " << pat->meet_ath_ID_num << endl;
Pt_ath[pat->meet_ath_ID_num] = pat;
cout << "\n test 2";
His example text file doesn't look like 2048 characters, does it?
Still wrestling with your athletes? :P
Does the second getline() crash too, if you comment out the first one?
cout << "\n" << i << " " << pat << endl;
What is that supposed to print out? Have you defined operator<< for Athlete* or does it print a pointer value?
You are reading the array index from a file. That seems pretty unsafe to me. It might be greater than 500, or twice the same. Maybe it's better to use a map<int, Athlete*> here.
But I cannot find the real cause of the trouble. It's hard to read such a large program.
You can try recreate the problem in a smaller context.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The cout is just put there to show what progress the program is making. If was to just run the program I would comment that out. I put it in like the test 2 and test 3, to see where the problem was and what the computer was seeing. pat is a pointer to Athlete, so it is just showing an address. With the error message I was seeing on the crash - I was wondering if pat was one of the listed addresses, but it is not.
The 500 is a maximum of athletes for the meet, 13 teams with maybe 30+ athletes per team. That array is going to be nice to connect the event entrants back to the Athletes.
The getline is to retrieve stored info.
The array is created mostly at run/retrieve time since that is when the pointers(Athlete's) memory is called (and would not be the same everytime the program runs - different computers - additional athletes)
That array is just storing the pointers for the athletes.
Maybe I wrote it wrong, but the second getline is the one that is crashing - the first works fine.
BUT if I use debug on the same program, with the breakpoint being 'anywhere', the program works fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried commenting out the first getline, and the program does not crash with a message as before, but 'quits' and goes back to the code section. I've put in a couple of pause statements so I can keep track of the progress.
I'm guessing that because the file now does not match with the requests that something is happening. There are actually 3 athletes in the first file, and it reads 1 and the start of the 2nd before stopping(aborting).
A proper run would read all 3 athletes in this file and read the 4 and 3 athletes in other files, and then read the event entrants.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> BUT if I use debug on the same program, with the breakpoint being 'anywhere', the program works fine.
This is typical for memory allocation-related issues, as the runtime environment would be different in a debug build.
HOWEVER, it is correct that you seem to make many assumptions about your input data, and thus it is probably a good idea to use some SEH (throw/catch).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
just to make sure that the problem really isn't related to the (non-validation of the) input data that you use, have you actually tried reproducing the problem with different sets of data/files?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, IF you are using data without further validation, it may in fact be corrupt/incorrect data which can result in showing similar behaviour to memory allocation issues, as you are basically dealing with uninitialized/undefined memory in the following code.
So, you should probably make sure that this is really NOT related to the data you are processing, i.e. by using a hardcoded set of data in order to see if the issue remains the same or not.
If it does, then your code is unlikely to be related to the individual data that's being processed, however if it does not, then you are probably having problems with the underlying data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
likewise, if a downstripped and less-complex version of your program parses and processes the same data (files) without crashing, you could probably assume that there's in fact a memory allocation issue in your original code.
So, this is all about troubleshooting the problem to see where the cause lies
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to find the addresses with this before the getline last_name with this: &(pat->last_name), and then I did the same after the first getline and before the second (for first_name) and it seemed that the 2 addresses were always 8 bytes apart.
Is that to be expected, especially after the last_name has been entered?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PLEASE try to follow the advice previously given, the size of a pointer or the interval between multiple consectutively defined pointers doesn't have any bearing on the DATA (in memory) it POINTS to, that is a pointer (address) doesn't change only because you populate the memory it points to with data.
To simplify the task of Meet_team::retrieve_team_athletes you could define an operator>> for Athlete.
Another thing you can try: add constructors and destructors to Athlete and Indvid. I don't think it will work, but you can try. It might initialize the string members.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess part of what I was wondering was whether the string parts of Athlete were put in as strings, or whether there is actually a pointer to each member(string) of the class?
Apparently each of the string members has its own pointer to the string.
Also I'm not sure what BTW stands for. Would there possibly be a problem with the getline function, instead of the string being read? Why would getline work in the debug, but not regularly if it is reading the same data?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those string members are put in as references to a string object, which is not the same as a char*.
If you want to squash this bug, what about:
-creating an empty project,
-copying the retrieve_blabla function in it along with the Pt_ath[500] declaration. Change the name of the function into
int main()
and do not copy any classes or other stuff
-step by step remove all overhead until you have only the bug left.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using Dev-C++ 4.9.9.2 on a Dell PC using Windows XP and Pentium 4.
I have had this problem for a couple of days. I run the program, and it crashes. I try to use the debugger to find out why(and where) I have a problem, and the program runs fine - no errors.
When it crashes I see:
Project_track_seed_r.exe - Application Error
with a red circle with a white x with:
The instruction at "0x77f580db" referenced memory at "0x00000000". The memory could not be "written".
Click on OK to terminate the program
Click on CANCEL to debuf the program
with OK and Cancel boxes.
it happens during this section of code:
cout <<"\ni " << pat->meet_ath_ID_num ;
Pt_ath[pat->meet_ath_ID_num] = pat;
getline(fin, pat->last_name);
getline(fin, pat->first_name);
cout <<"\ni " << pat->meet_ath_ID_num << " " << pat->last_name;
The first cout prints, but the second does not.
When I run the debug it will run right thru this section and immediately print the 2nd cout also.
Same situation yesterday, the only difference was the error message was different, but the regular run crashes and the debugger runs right thru this section with no problem.
please provide a downstripped sample of your source code that shows the same behaviour, otherwise it is basically impossible to tell where exactly you fail to do your memory allocation properly.
Are pat->first_name and pat->last_name C-style strings? Then you may have not allocated memory for them before the getline() calls.
I agree with the first answer, you could show us the declarations of your variables and how you initialize them. Also you can do a cout after each line, so you can tell us more precisely which line causes problems.
Here are some of my declarations:
Athlete* Pt_ath[500];
class Indvid
{
public:
};
class Athlete : public Indvid
{
// protected:
public:
};
extern Athlete pat;
extern Athlete Pt_ath[];
When I put in the couts, the crash happens after the getline last_name - apparently with the getline first_name.
Here is the start of the textfile copied and pasted:
3
Bixler
Travis
9
0
1
1
1
I appreciate the effort to help.
> Athlete* Pt_ath[500];
What exactly do you think/hope/intend to do with that statement? Do you actually do any additional initialization later on in your source code?
And apart from that:
1) please provide a self-contained (and minimal )piece of source code (i.e that compiles) that shows the same behaviour
2) your variables don't seem to be named intuitively, if you cannot change the variable names, please consider commenting the purpose of each variable
3) commenting your sources in general, would be an awesome idea as it can significantly simplify the process of enabling other people to understand (the intentions that made you write) your source code
You need to understand, that good source code shouldn't require an extraordinary amount of time to understand it, even if you haven't written it yourself-people should be able to understand it fairly quickly. Picking proper variable names, as well as adding useful comments can be tremendously helpful. In particular, if you are new to programming, there's hardly anything wrong with commenting "too much", simply because it will enable other people to understand what you are trying to do with your source code, in plain English.
Another thing you might take into consideration, would be to replace constants with preprocessor macros or even global constant variables using telling names, so that people will be able to understand these constants immediatley.
Also, I am just about to actually understand the naming of your variables, and would advise you to either follow more established naming conventions or simply use plain English instead of the hybrid mix that you currently employ, simply because it creates additional complexity.
For example:if you name one class "Athlete", why don't you simply name the parent class "Individual" rather than only "Indvid", which leaves room for guessing? Likewise, you seem to be somewhat ambivalent concerning the naming of your pointer variables (using once prefix "pt_" and then only "p").
I am including the whole function:
I put *** where the problem exists. Test 2 and test3 print and then crashes when executing. But when I use the debugger, there is no problem.
// function - retrieve the athletes for a meet
int Meet_team::retrieve_team_athletes(string code, Meet_team pmt)
{
int i = 0, j;
Athlete pat2;
string file_name = code + "ath" + pmt->team_abbr;
// cout << "\nThe textfile name * 17 * is "<<file_name << endl;
// cout << "\nThe textfile name * 27 * is "<<file_name << endl;
*** getline(fin, pat->last_name);
cout << "\n Test 3";
getline(fin, pat->first_name);
cout <<"\ni " << pat->meet_ath_ID_num << " " << pat->last_name
<< endl;
fin >> pat->grade >> ws;
for (j = 1; j <= pmi->num_of_events; j++)
{
fin >> pat->ath_ev[j] >> ws;
pat->num_of_ath_events += pat->ath_ev[j];
}
/ cout <<"\n" << i << "pat->pHead_ath " << pat->pHead_ath;
cout << "\n" << pmt << " " << pmt->pHead_tm_ath;
/ }
}
I can even put the cursor well past this point, and when I debug, and 'run to cursor' it runs fine. But not without the debugger.
> getline(fin, pat->last_name);
what exactly are you trying to do with that statement?
How about the following:
fin.getline(pat->lastname,2048); //max buffer size
His example text file doesn't look like 2048 characters, does it?
Still wrestling with your athletes? :P
Does the second getline() crash too, if you comment out the first one?
cout << "\n" << i << " " << pat << endl;
What is that supposed to print out? Have you defined operator<< for Athlete* or does it print a pointer value?
You are reading the array index from a file. That seems pretty unsafe to me. It might be greater than 500, or twice the same. Maybe it's better to use a map<int, Athlete*> here.
But I cannot find the real cause of the trouble. It's hard to read such a large program.
You can try recreate the problem in a smaller context.
The cout is just put there to show what progress the program is making. If was to just run the program I would comment that out. I put it in like the test 2 and test 3, to see where the problem was and what the computer was seeing. pat is a pointer to Athlete, so it is just showing an address. With the error message I was seeing on the crash - I was wondering if pat was one of the listed addresses, but it is not.
The 500 is a maximum of athletes for the meet, 13 teams with maybe 30+ athletes per team. That array is going to be nice to connect the event entrants back to the Athletes.
The getline is to retrieve stored info.
The array is created mostly at run/retrieve time since that is when the pointers(Athlete's) memory is called (and would not be the same everytime the program runs - different computers - additional athletes)
That array is just storing the pointers for the athletes.
Maybe I wrote it wrong, but the second getline is the one that is crashing - the first works fine.
BUT if I use debug on the same program, with the breakpoint being 'anywhere', the program works fine.
I tried commenting out the first getline, and the program does not crash with a message as before, but 'quits' and goes back to the code section. I've put in a couple of pause statements so I can keep track of the progress.
I'm guessing that because the file now does not match with the requests that something is happening. There are actually 3 athletes in the first file, and it reads 1 and the start of the 2nd before stopping(aborting).
A proper run would read all 3 athletes in this file and read the 4 and 3 athletes in other files, and then read the event entrants.
> BUT if I use debug on the same program, with the breakpoint being 'anywhere', the program works fine.
This is typical for memory allocation-related issues, as the runtime environment would be different in a debug build.
HOWEVER, it is correct that you seem to make many assumptions about your input data, and thus it is probably a good idea to use some SEH (throw/catch).
just to make sure that the problem really isn't related to the (non-validation of the) input data that you use, have you actually tried reproducing the problem with different sets of data/files?
I tried taking away the first teams' list of athletes, and now it is crashing after test 2 (i.e. with the first getline).
Somebody mentioned memory allocation issues. I have just declared a NEW athlete that I am trying to populate. What is SEH? How does it work?
I took another team file away, and it ran the first ahlete, but crashed on the first getline of the 2nd athlete.
SEH=Structured Exception Handling: http://en.wikipedia.org/wiki/Structured_Exception_Handling
http://www.cppreference.com/keywords/try.html
http://www.cplusplus.com/doc/tutorial/exceptions.html
It allows you to check for conditions that would otherwise cause segfaults, i.e.:
//--------pseudo code
include <iostream>
int main()
{
using namespace std;
int a=100,b=0,result=0;
try {
result=a/b;
}
catch(...)
{
cout << "Problem:" << endl;
}
return 0;
}
//----------
However, IF you are using data without further validation, it may in fact be corrupt/incorrect data which can result in showing similar behaviour to memory allocation issues, as you are basically dealing with uninitialized/undefined memory in the following code.
So, you should probably make sure that this is really NOT related to the data you are processing, i.e. by using a hardcoded set of data in order to see if the issue remains the same or not.
If it does, then your code is unlikely to be related to the individual data that's being processed, however if it does not, then you are probably having problems with the underlying data.
likewise, if a downstripped and less-complex version of your program parses and processes the same data (files) without crashing, you could probably assume that there's in fact a memory allocation issue in your original code.
So, this is all about troubleshooting the problem to see where the cause lies
You can try recreating the problem in an empty project.
I tried to find the addresses with this before the getline last_name with this: &(pat->last_name), and then I did the same after the first getline and before the second (for first_name) and it seemed that the 2 addresses were always 8 bytes apart.
Is that to be expected, especially after the last_name has been entered?
PLEASE try to follow the advice previously given, the size of a pointer or the interval between multiple consectutively defined pointers doesn't have any bearing on the DATA (in memory) it POINTS to, that is a pointer (address) doesn't change only because you populate the memory it points to with data.
http://www.cplusplus.com/doc/tutorial/pointers.html
http://www.cplusplus.com/doc/tutorial/dynamic.html
If you are really interested in sorting this out, please follow the troubleshooting guidelines that we have given you already.
BTW getline(fin, pat->last_name); is correct.
To simplify the task of Meet_team::retrieve_team_athletes you could define an operator>> for Athlete.
Another thing you can try: add constructors and destructors to Athlete and Indvid. I don't think it will work, but you can try. It might initialize the string members.
I guess part of what I was wondering was whether the string parts of Athlete were put in as strings, or whether there is actually a pointer to each member(string) of the class?
Apparently each of the string members has its own pointer to the string.
Also I'm not sure what BTW stands for. Would there possibly be a problem with the getline function, instead of the string being read? Why would getline work in the debug, but not regularly if it is reading the same data?
BTW: google: "internet acronyms" -> "By The Way"
BTW is short for by the way, and as I said
your getline() call is just correct.
Those string members are put in as references to a string object, which is not the same as a char*.
If you want to squash this bug, what about:
-creating an empty project,
-copying the retrieve_blabla function in it along with the Pt_ath[500] declaration. Change the name of the function into
int main()
and do not copy any classes or other stuff
-step by step remove all overhead until you have only the bug left.