rev2009 (Win-DGI+SDL) pak128 crash stop-mover

[whoami]

(I don't know whether this is caused by continuing an old savegame in recent versions:)

I always get a crash "Access Violation" in this savegame when using the stop-moving tool (from the road menue) for the bus station "Dresden Kornfeld S" (click on one of the two tiles to the right, then on the one to the left). Simu.log and Dr.MinGW don't show anything useful, therefore, this may be a different bug (which may have been fixed by now).

Use a recent nightly build of Pak128 for this savegame (e.g. rev. 61 or 87).

(Thanks to Frank for supplying a file hosting service for purposes like this.)

EDIT/UPDATE: rev.2011 aborts at loading this savegame:
FATAL ERROR: vector_tpl<T>::[] / index out of bounds: 1 not in 0..-1 / Aborting program execution ...
and the problem can't be reproduced with the same origin savegame. Therefore, the savegame may be broken, and only rev.2011 detects that.
EDIT^2: rev.2011 aborts with this error even on some of its own autosaves.

[z9999]

This problem seems to be caused by empty schedule vehicle which is in depot.

How to reproduce:
1. Build two stop
2. Build depot
3. Buy vehicle
4. Select stop moving tool
5. Click one stop and click the other stop

Result:
Crash.

simutrans-.exe caused an Access Violation at location 00558c2c in module simutrans-.exe Reading from location 00000000.

Registers:
eax=00000000 ebx=05aecc50 ecx=0023f150 edx=00000004 esi=006d0074 edi=00730070
eip=00558c2c esp=0023f038 ebp=0023f298 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000212

Call stack:
00558C2C  simutrans-.exe:00558C2C  wkz_stop_moving_t::work(karte_t*, spieler_t*, koord3d)  simwerkz.cc:3320
   ...
   fahrplan_t *fpl = cnv->gib_fahrplan();
   // check waytype
>   if(fpl->ist_halt_erlaubt(bd)) {
   bool updated = false;
   for(  int k=0;  k<fpl->maxi();  k++  ) {
   ...

[whoami]

This problem seems to be caused by empty schedule vehicle which is in depot.

And this vehicle also prevents rev.2011 from loading the savegame, see here, right?

So this bug report is still valid - and the problem actually came to my attention with a rev.1957 executable.

[whoami]

Seems to be resolved.