Runtime error using cout after ifstream

I've been working on one little bug for the longest time (a few hours yesterday and I'm starting again today). I know the exact line of code my program crashes at, but the thing is... it's just a simple cout statement.

i.e. cout << entry << endl;

When I print entry with GDB before this line executes, I get the following:

$1 = {_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x100100ea8 " How old are you? "}, static npos = 18446744073709551615}

Or as I read this: entry = " How old are you? "

I cannot, for the life of me, figure out why this happens. The only thing I can think of is that there must be an issue with how entry gets assigned while I'm using ifstream. And yet, I can walk through that part of the ifstream process and print the variables out to check them and it's working just fine! So I really don't know.

I can't just paste a little bit of code because it wouldn't be helpful. The whole program is a few hundred lines of code spread throughout ~7 classes, so I'd rather just get an answer from the information I provided but I know that is unlikely. Let me know if anyone is interested in downloading it and how I can do that, since I'm new to CS forums. Thanks for the help!
Last edited on
Just because a program crash at a certain line doesn't mean that line is to blame. It could very well be some other part of your program that do something bad. You could try run your program with valgrind and see what you get.
You need to learn to isolate issues.
First, ¿why did you wait for your program to be so big to start testing?
Peter87, I realize that and I've looked around a lot. Good suggestion with valgrind, I'll be sure to do that as soon as I get it running on my computer.

ne555: I haven't. I've tested lots and lots but you're somewhat correct because I probably added too many functionalities before testing again. I added the new ifstream functionality (originally it was input from a .txt, now it's .csv). This used to work fine at some point. But I also added an ofstream function (for saving abilities), but the program doesn't even get to the saving point before it crashes. I've obviously made the mistake of changing lines and forgetting what I changed that makes it crash. It used to cout that line perfectly fine.

Anyways I made a mistake and I've learned from that. To continue the thread, can anyone make any more suggestions as to why it crashed? Has anyone had a similar problem when they used fstream? Some more info: if I run it in command prompt (or terminal in my case), it'll output spaces infinitely. If I run it in an IDE, that's when it freezes up and takes ~10sec to quit my program.
Update on things: I got valgrind up and running, and my program works like it's supposed to when I use valgrind, which I find strange. But it did output this:


==38277== Invalid read of size 8
==38277== at 0x100005A1E: Station::getAnswer(int) (Station.h:73)
==38277== by 0x1000060CC: Assembly::getAnswer(int) (Assembly.h:58)
==38277== by 0x1000061AF: Job::getAnswer(int) (Job.h:37)
==38277== by 0x10000193D: main (maincmd.cpp:54)
==38277== Address 0x100011f58 is 8 bytes inside a block of size 56 free'd
==38277== at 0xC508: free (vg_replace_malloc.c:430)
==38277== by 0x100002317: Assembly::~Assembly() (Assembly.h:19)
==38277== by 0x1000023A2: Job::~Job() (Job.h:34)
==38277== by 0x1000053D2: list::list() (list.h:36)
==38277== by 0x10000176F: main (maincmd.cpp:28)
==38277==
==38277== Invalid read of size 1
==38277== at 0x100001A8C: Verification::isEntry() (Verification.h:31)
==38277== by 0x100005A42: Station::getAnswer(int) (Station.h:73)
==38277== by 0x1000060CC: Assembly::getAnswer(int) (Assembly.h:58)
==38277== by 0x1000061AF: Job::getAnswer(int) (Job.h:37)
==38277== by 0x10000193D: main (maincmd.cpp:54)
==38277== Address 0x1000120d8 is 56 bytes inside a block of size 128 free'd
==38277== at 0xC508: free (vg_replace_malloc.c:430)
==38277== by 0x10000226C: Station::~Station() (Station.h:19)
==38277== by 0x1000022F8: Assembly::~Assembly() (Assembly.h:19)
==38277== by 0x1000023A2: Job::~Job() (Job.h:34)
==38277== by 0x1000053D2: list::list() (list.h:36)
==38277== by 0x10000176F: main (maincmd.cpp:28)
==38277==

The program still doesn't work when I'm not using valgrind. If anyone can decipher this output by valgrind that'd be helpful. In the meantime, I'll still be trying to fix the error / deciphering it myself.
Last edited on

==38277== Invalid read of size 8 ==38277== at 0x100005A1E: Station::getAnswer(int) (Station.h:73)

In the file named Station.h at line 73, in the function Station::getAnswer(int), 8 bytes are being read from memory that is not yours to read from.

Similarly for
==38277== Invalid read of size 1
==38277== at 0x100001A8C: Verification::isEntry() (Verification.h:31)
Thanks Moschops. I'm glad I can understand and use a powerful tool such as valgrind now. I'm not sure what it means when you say "memory that is not yours to read from."

Either way I'm going to go ahead and rewrite the loading functions. Right now my load/save is from the same file which is a .csv file that has to look all nice when opened in Excel so that people can easily read the information. Instead I'm going to load/save from a .txt file, but also save (and not load) to a .csv file. That'll make things much less messy and much easier to do when using ifstream.

Well back to coding, I'll be back in a bit with hopefully a working program.
Last edited on

"memory that is not yours to read from.


But valgrind explained it to you what it means:

Address 0x100011f58 is 8 bytes inside a block of size 56 free'd by 0x100002317: Assembly::~Assembly() (Assembly.h:19)

So it means, you called free on something and afterwards you are trying to access the already freed memory.
So either you don't want to free that memory in the Assembly destructor (or you free wrong pointer) or you don't want to access it in getAnswer.
Last edited on
Thanks for the reply rapidcoder. I rewrote my loading functions and now it works, but I don't know why [insert relevant xkcd comic here]. Oh well! Thanks for all the help guys / gals.
Topic archived. No new replies allowed.