access violation error in Busstop::passenger_activity_at_stop after reset. Passengers reading from generated transit paths does not work properly between resets.

[Trateotu]

With the SF network currently in our shared dropbox folder (Todays date: 2018-06-22) and a debug build of our current busmezzo_test I receive an access violation error in Busstop::passenger_activity_at_stop when boarding passengers after the simulation has been reset. Arguments I used are: "mezzo_s masterfile.mezzo 2 1"

``// Boarding passengers

    for (map <Busstop*, ODstops*>::iterator destination_stop = stop_as_origin.begin(); destination_stop != stop_as_origin.end(); destination_stop++)
    {
        // going through all the stops that this stop is their origin on a given OD pair
        passengers pass_waiting_od = (*destination_stop).second->get_waiting_passengers();
        if (pass_waiting_od.empty() == false) // if there are waiting passengers with this destination
        {
            passengers::iterator check_pass = pass_waiting_od.begin();
            Passenger* next_pass;
            bool last_waiting_pass = false; 
            while (check_pass < pass_waiting_od.end())
            {
                // progress each waiting passenger  
                ODstops* this_od = this->get_stop_od_as_origin_per_stop((*check_pass)->get_OD_stop()->get_destination());

[Trateotu]

@burghout @OdedCats False alarm! I tried again and am not receiving this error anymore so probably the issue was on my side.

[Trateotu]

Ok false - false alarm. Jonas ran into this error as well using the same SF network in our dropbox.

The issue pops up when using multiple replications and with the choice_set_indicator= 0 (to generate transit paths). First replication seems to work ok, and possibly the second (which is odd) but with replications > 2 we get a crash. The arguments both Jonas and I used to generate this error with the SF network in our dropbox are replications= 10 and random seed= 0. Passengers reading from the generated transit paths does not seem to work properly then between resets.

If o_path_set_generation is created in the first replication and updated to be read as path_set_generation (@OdedCats how to do this should probably be added to the I/O doc) then replications > 2 seems to work fine with choice_set_indicator= 1.