[Freeciv-Dev] (PR#11081) IDEX: unit collision

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=11081 >

> [marko.lindqvist@xxxxxxxxxxx - Fri Nov 19 07:21:33 2004]:
> 
> 
>   In very long autogame (run until endyear 5000) I got these messages. 
> Second number in messages is game.year (added by my own log callback).
> 
> 1: +4569:IDEX: unit collision: new 3929 0x1a8e9720 Transport, old 3929 
> 0x1072b8a0 Caravan
> 1: +4627:IDEX: unit collision: new 5283 0x1c20f050 Settlers, old 5283 
> 0x10761ae8 Caravan
> 1: +4710:IDEX: unit collision: new 7316 0x1d7e01c8 Transport, old 7316 
> 0x10745fb8 Caravan
> 1: +5001:IDEX: unit unreg missing: 7316 0x10745fb8 Caravan
> 1: +5001:IDEX: unit unreg missing: 5283 0x10761ae8 Caravan
> 1: +5001:IDEX: unit unreg missing: 3929 0x1072b8a0 Caravan
> 
> 
>   Note that I were using custom rulesets and server options were far 
> from default.

I think we need more information to find the problem.

If a unit is allocated and never deallocated, then running under a
memory (leak-check) debugger would show where the unit was first
allocated.  However this would take a very long time.

It's also possible the unit is allocated and deallocated, but is not
deallocated by server_remove_unit so the ID is never unregistered.  This
seems particularly likely because all the errors are with caravans:
something to do with the AI caravan calculations perhaps.  In this case
a memory debugging run probably wouldn't help.

But perhaps this whole argument misses the point of the error.  Simply
failing to unregister a unit wouldn't cause this problem.  The question
is how a new unit can receive an ID that's already in the registry.  And
for this a simple backtrace (by setting IDEX_DIE to TRUE and rerunning
the autogame) may help track it down.

Interestingly it seems like if a game has more than ~65,000 units in it
living at one time the server will fail with an infinite loop.  See
dealloc_id().

jason