Aircraft queueing & planespeed

[DaleStan]

Is it always the same vehicle that breaks? If so, try setting a data breakpoint on the offending variable.

[CobraA1]

I suppose if I release the airplanes while its paused and always in the same order, it might work. However, I do not seem to consistently get the same memory locations when OpenTTD is restarted.

I created a data breakpoint, and told it to continue when hit, recording information, and obtained this:

Code: Select all

Function: memset(unsigned char *, unsigned char, unsigned long), Thread: 0x5E8 __tmainCRTStartup
The thread 'Proxy' (0x17a8) has exited with code 0 (0x0).
Function: memcpy(unsigned char *, unsigned char *, unsigned long), Thread: 0x5E8 __tmainCRTStartup
Function: fastcopy_I(void *, void *, int), Thread: 0x5E8 __tmainCRTStartup
The thread 'Win32 Thread' (0x1090) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x15b4) has exited with code 0 (0x0).

Doesn't really tell me much, except that internal memory copying routines have been writing to it.

The internal items of v->queue_item are filled with the hexidecimal "0xfeeefeee" - which tells me it's sitting in freed memory in the heap.

http://en.wikipedia.org/wiki/Magic_numb ... bug_values

Which makes me wonder - where is it getting freed, and why?

Here's the call stack of the memory location that gets changed right before it crashes:

Code: Select all

 	ntdll.dll!_RtlFillMemoryUlong@12()  + 0x10 bytes	
 	ntdll.dll!_RtlpInsertFreeBlock@12()  + 0xbc1b bytes	
 	ntdll.dll!_RtlpExtendHeap@8()  + 0x50 bytes	
 	ntdll.dll!@RtlpAllocateHeap@20()  - 0x35f9b bytes	
 	ntdll.dll!_RtlAllocateHeap@12()  + 0xb1f bytes	
 	ntdll.dll!_RtlDebugAllocateHeap@12()  + 0xb5 bytes	
 	ntdll.dll!@RtlpAllocateHeap@20()  + 0x1bb26 bytes	
 	ntdll.dll!_RtlAllocateHeap@12()  + 0xb1f bytes	
 	openttd.exe!_heap_alloc_base(unsigned int size=65572)  Line 105 + 0x28 bytes	C
 	openttd.exe!_heap_alloc_dbg(unsigned int nSize=65536, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0)  Line 411 + 0x9 bytes	C++
 	openttd.exe!_nh_malloc_dbg(unsigned int nSize=65536, int nhFlag=0, int nBlockUse=1, const char * szFileName=0x00000000, int nLine=0)  Line 268 + 0x15 bytes	C++
 	openttd.exe!malloc(unsigned int nSize=65536)  Line 154 + 0x15 bytes	C++
 	openttd.exe!_zcalloc()  + 0xf bytes	C
 	openttd.exe!_deflateInit2_@32()  + 0x17e bytes	C
 	openttd.exe!_deflateInit_@16()  + 0x21 bytes	C
>	openttd.exe!InitWriteZlib()  Line 1194 + 0x13 bytes	C++
 	openttd.exe!SaveFileToDisk(bool threaded=true)  Line 1543 + 0xa bytes	C++
 	openttd.exe!SaveFileToDiskThread(void * arg=0x00000000)  Line 1574	C++
 	openttd.exe!Proxy(void * arg=0x035b2060)  Line 120 + 0x10 bytes	C++
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x27 bytes	

Doesn't really make sense to me - saveload.cpp is messing with my memory? Why? I hope the memory location didn't change when restarting OpenTTD. Nothing's really making sense to me.

What would be really nice is if there were some debugger capable of recording the history of a selected variable, such as this one:

http://www.lambdacs.com/debugger/USENIX ... _2003.html

Alas, that one is for Java, and is mostly concept.

[CobraA1]

Updated my (broken) patch for the current trunk. Help wanted.

EDIT: I resolved the issue.

Here's what happened:

-When I switched to C++, I made the queue is independent of the data being used; it can wrap any type of data inside an IndexedItem and doesn't touch the data. This means that the items in the queue are unaware that they're in the queue.

-However, it is often important (indeed, vital to my patch's function) to find which queue (and where in the queue) the item belongs to using just the data.

-In order to do this, I added a field (queue_item) in the Vehicle type that stores which IndexedItem the vehicle belongs to (which in turn knows which queue it belongs to, and what its position in the queue is).

-This means that every time I push a Vehicle into a queue, I have to set queue_item to the right IndexedItem. I also have to set it to NULL when I pop it.

I found that I had popped it once without telling setting queue_item to NULL - so when it got popped, it pointed to an IndexedItem that had been deleted. So the next time the vehicle was asked which queue it belonged to, it returned an invalid result instead of a NULL.

Pointer based languages are such a pain to debug.

[CobraA1]

I'm pleased to announce a new release of my patch!

This release fixes some outstanding issues with the patch, such as bugs and poor wording (8x is now "fastest" rather than "realistic" in the speed part of the patch).

The speed portion of the patch still has some known bugs.

The biggest changes are in the queuing and the single runway airports: I have added a new "descent" phase to the landing at the single runway airports, and have made some changes to the country airport to make it handle a bit more landed traffic (at the expense of airplanes occasionally overlapping).

The changes I've made should make the landing sequence more realistic and should allow the airports to handle more traffic, at least as landing is concerned.

The airports with multiple runways have not been modified and will not be affected.

Due to the nature of the airport state machine, many of the changes are permanent and can't be turned off! There's nothing I can do about that - the state machine is hard coded.

I noticed that RichK is working on moving the airport to a separate file - I'd be interested in that, perhaps by creating my own file, I could make it patchable? I'll try to contact him about it, as his branch of the code could affect my patch.

[CobraA1]

Sorry for taking so long between updates, real life just gets in the way. I've updated it for SVN so it doesn't conflict. Other than that, no changes.

Anybody want to help keep it up to date?

[CobraA1]

Well, I decided to play a game with my patch - and it crashed, lol. So here's a bugfix, and oh, yeah: The planespeed stuff is no more. It throws off the economy too much, it's one more thing to keep track of, and aircraft speeds were fixed in the trunk anyways. From now on, this patch is only about the aircraft queuing system.

So enjoy the bugfix, which also solves a slight conflict with the nightlies.

[CobraA1]

Updated to match the nightlies.

[CobraA1]

Sorry, but development has been suspended indefinitely unless somebody else picks it up. I just don't have the time anymore.

[Gedemon]

I've tried to update a portion of CobraA1's patch, I hope I've not broken anything...

There are two parts :

- the queue patch without any change to airport movement
- modified holding area for most airports so that queued planes do not spend too much time in large circles before landing

[Batti5]

Vecicles can be deleted from middle of queue

It is Ridicules, in reality you can`t disabmle or sale a plain in mid air, or you ment redircting it to an other airport,
And its called "Vehicles" not "vecicles" get it?

[Niek]

It's also called 'ridiculous', 'disable', 'sell', 'plane', 'meant' and 'redirecting'

[DaleStan]

Furthermore, it's 'called' "it's", not "its"

[CobraA1]

The "queue" is the internal data structure in the code. It's a bunch of pointers to the aircraft, and each airport has one or more queues representing the order of landing in my patch.

. . . and this patch probably doesn't work anymore anyways, as it doesn't seem anybody is updating it. Sorry, I still can't update it myself.

[Gedemon]

here's an update of the queue patch only.

It should be used with the new holding pattern patch for efficiency.

[2007Alain2007]

Hi i just tryed that patch and went to conpile it to R17532 and R17510 and it kicked out errors on both

Code: Select all

In file included from C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../vehicle_base.h:32,
                 from C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/ai_instance.cpp:15:
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:14: error: declaration of `class T'
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:12: error: shadows template parm `class T'
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:21: error: ISO C++ forbids declaration of `IndexedQueue' with no type
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:21: error: expected `;' before '<' token
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:27: error: ISO C++ forbids declaration of `IndexedQueue' with no type
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:27: error: expected `;' before '<' token
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp: In constructor `IndexedItem<T>::IndexedItem()':
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:346: error: `queue' was not declared in this scope
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp: At global scope:
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:366: error: no `IndexedQueue<T>* IndexedItem<T>::getQueue()' member function declared in class `IndexedItem<T>'
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:366: error: template definition of non-template `IndexedQueue<T>* IndexedItem<T>::getQueue()'
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp: In member function `IndexedQueue<T>* IndexedItem<T>::getQueue()':
C:/msys/1.0/home/Alainspc/ottdsrc/trunk/src/ai/../indexed_queue.hpp:367: error:  `queue' was not declared in this scope
make[1]: *** [ai/ai_instance.o] Error 1
make[1]: Leaving directory `/home/Alainspc/ottdsrc/trunk/objs/release'
make: *** [all] Error 2