Are you sure everything is initialised? Look at the code with a debugger to see that is actually happening. :+)
What does the code that calls a segment constructor look like? I trying to imagine an orderly system whereby everything is initialised, then a coherent way of accessing and processing the data. At the moment, I don't get that feeling reading your code.
In my mind, you have too much happening in the void mySystem::snapshotDisk() function. Consider splitting it by making some private functions if you need to. Functions should do one conceptual thing.
Also, you have a lot of friend classes, effectively sharing the data between all the classes: doesn't sound good. Consider using the interface of each class to retrieve data, rather than sharing all of it.
Do you have a particular reason, like needing polymorphism, as to why you have so many pointers? C++11 has move semantics, so one can have a container of objects, rather than a container of pointers to objects.
There is also std::reference_wrapper , so you can have a container of references, if really needed - maybe not.
The first thing I would look at is: Where are the Segment objects stored that segTable is pointing to? Is it possible they're in a container that invalidates pointers to elements when it is resized?
Does PCB::insertSegTable validate pointers added?
But, mostly the first question. Where are these objects that are pointed to stored?
To be honest I am just rushing through the coding since it was just homework. I didn't have a lot of time to flesh everything out, but I intend to do that after the semester is over. I am just trying to get the basics done and submit a working program on time.
I didn't have a lot of time to debug yesterday, but I am currently trying to recover from a previous version of the program. The previous version there was no segmentation fault at all, and when I implemented something, which I don't remember what, it started giving segmentation faults.
I was trying to create a pointer to the newly inserted Segment object. So I needed access to it. Since list insertion inserts into position previous to current iterator, I needed another iterator to backtrack by one position after insertion to get the newly inserted Segment. Then I created a pointer to it and then inserted it into the PCB's vector<Segment*> segTable;.
I was trying to create a pointer to the newly inserted Segment object. So I needed access to it.
Aha. It's rare I find the need to use std::list. My thought process was that you might decrement an iterator past the begin iterator, but that checks out.
Here's what I think is happening. You "erase" a Segment (see line 40 in memory::allocate) which is pointed to by pointer contained in your vector, and then you try to dereference that pointer to the no longer existing Segment.
Here's what I think is happening. You "erase" a Segment (see line 40 in memory::allocate) which is pointed to by pointer contained in your vector, and then you try to dereference that pointer to the no longer existing Segment.
I don't think that is the error. memItr always points to a "hole" or an empty segment that doesn't belong to any PCB. The code never inserts a hole into vector<Segment*> segTable;. Unless it is somehow possible I still did it?
I don't see anything that would prevent it. Your Segment objects are stored in the same list, and from your class definition, the hole_ member will be set to true in the Segment added to the list.
I don't see anything that would prevent it. Your Segment objects are stored in the same list, and from your class definition, the hole_ member will be set to true in the Segment added to the list.
Oh, right, segToInsert.fill(); "fills" the hole and sets hole_ to false.
Then it seems I've reached the limit of my look-it-over-debugging given the code you've supplied. Using a debugger or instrumenting the code to log what's happening during execution would probably be a good next step for you.
Well it turns out Segment* inside vector<Segment*> segTable; is invalidated and recreated with different addresses after the PCB went out of scope. So I guess I have to dynamically allocate PCB object so this doesn't happen.