ware: can't move from building 12386 to 7689 (not a warehous

Logged In: YES
user_id=1392996
Originator: YES

files are to big ... I'll upload them to http://xoops.widelands.org/bugs/1935868

Logged In: YES
user_id=31104
Originator: NO

Duplicate of #1690070.

I reopened the bug, as I can reliable reproduce it with current source.
I was not able to find the bug which this was the dublicate of (perhaps it got removed in the move from SF.net?) so I suggest to track the bug here from now on.
I will attach a savegame that allows to reproduce the problem by simply loading and waiting a few seconds.

Very strange.

I added better output in revision 5479 and reloaded the savegame above.
Errormessage is now:

[src/economy/ware_instance.cc:371] MO(2474): ware(meat): can not move from building 3396 (constructionsite at (60,23)) to 2781 (flag) -> not a warehouse!

I checked that position. It's a tavern that gets enhanced - there is no ware inside and it is still 0% build. The crash occurs when a chamoir enters the field of the flag.

I first thought about a hunter that might have shot the cahmoir (would explain the meat), but I was not able to see any sign of a hunter.

Any ideas?

The ware 2474 is already in the savegame. And it has a transfer attached. I think the bug happened somewhere earlier. Perhaps this is caused by upgrading the building while a ware was carried in or maybe it was caused by saving at a bad time? I try to find out what really comes from the savegame. But I think it will not contain much information how this happened.

well - exactly the same problem appeared before the emergency savegame (the one attached) was created. At that moment the game was played without any pause or reload, so it surely has nothing to do with "broken" saving.

However it sounds like a possible explanation, that the carrier was just about to put meat into the tavern, when it got upgraded by the computer player. But I haven't checked that yet

Hard to say if this is related to this bug. I started on checking Bug #667210 and as I could not reproduce it, I left new game running with the same map "The Long Way" and default 4 aggressive AIs. Game speed dropped after a while to around 1 fps and some time later Visual Studio broke to failed assertion in dafaultai.cc:791

 for
  (std::list<BlockedField *>::iterator i = blocked_fields.begin();
   i != blocked_fields.end();
-> ++i)
  if ((*i)->blocked_until < game().get_gametime())
   i = blocked_fields.erase(i);

blocked_fields is empty and iterator is pointing to poisoned value 0xcdcdcdcd.

Looking at the code it's easy to see that if final element is erased, i will be end marker and next code line will go ahead an increment it. On gcc this kind of bugs propably just corrupt heap silently until they crash.

Fixed in r5606. I could not load the attached savegame, so if someone knows how to reproduce the bug, please test if this fixed the bug. However if savegame is gotten when heap is already corrupted, then regression test is invalid. Still this bug sounds like heap corruption to me.

Jari, I agree with your analysis. Let's see for a while if this bug resurfaces.

We had this bug on our playday, the second game. Nicolai, did the replay reproduce this bug, if so, did you find anything?

I haven't had the time to investigate further, I hope to get to it next weekend.

I believe I have found the sequence of events that must happen to trigger this bug. It's really a quite subtle race condition, so no surprise that it happened so rarely.

1) An item is being transported somewhere, e.g. to a warehouse.
2) While being transported to the flag of a tavern (or other enhanceable building), the item's transfer is changed to go to that tavern. However, the item's m_transfer_nextstep is not updated before the carrier drops the item onto the flag. Alternatively, a new request for the item appears while the item is waiting on the flag to be fetched by a different carrier.
3) Now the tavern's worker is sent to fetch the item from the building's flag.
4) While the worker returns to the tavern carrying the item, the player enhances that tavern, turning it into a constructionsite.
5) The worker is reassigned to the constructionsite, but continues carrying the item into the site, ignoring the fact that this is not where the item wants to go.
6) The item ends up lost and confused inside the constructionsite and can't get back out.

I think I have a fix for this - by having fetchfromflag_update check whether the item still wants to go into the worker's building - but testing the patch takes some time (one test case is a replay of a 5+ hours game).

Well, Nasenbaer's save game still exhibits the bug because the item is already in a messed up position inside the savegame. However, I fixed the bug in the sense that such an inconsistent state should not be able to occur any more; at least the replay I tested this bug with is fixed.

Congratulations on this hunt, nicolai! Did you bring yourself a nice trophy?

Released in build16-rc1