VCMI 0.94d -- development version (r3728)

another development build is ready:

It brings a number of bugfixes, particularly for numerous crashbugs that were plaguing previous build.
Please test it, particularly to check if the previously reported campaign issues are gone.

Ah, save format should be compatible with previous build. And please try to keep it this way for now. :slight_smile:

One request for someone with Linux: please try running the savegame from let me know of the results.
It looks that Boost/WinAPI issue that makes it impossible to access TLS outside from the module that created thread. [so thread interruption can’t be detected in client, if the thread was created by AI.] I am curious if this works that way on Linux as well.

not runing. zlib.dll not found, system error

What exactly should I be looking for? This is what I get after running that save:

Sent info to server: 0
[New Thread 0x7fffde064700 (LWP 28782)]
[Thread 0x7fffe09af700 (LWP 28777) exited]
Warning: IntObject re-activated with mismatching used and active
[New Thread 0x7fffe09af700 (LWP 28784)]
[Thread 0x7fffe09af700 (LWP 28784) exited]
[New Thread 0x7fffe09af700 (LWP 28785)]
System message: You were identified as player 5 while expecting 1
System message: You are not allowed to perform this action!
System message: Server encountered a problem: Got false in applying... that request must have been fishy!
Cannot evaluate goal VISIT TILE (2 19 0) (Adelaide)
Cannot evaluate goal  (Shiva)
Cannot evaluate goal  (Clancy)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe09af700 (LWP 28785)]
0x00007fffb0765fc0 in ?? ()
(gdb) bt
#0  0x00007fffb0765fc0 in ?? ()
#1  0x00007fffe1d9a924 in VCAI::striveToGoalInternal (this=0x7fffbd15b508, 
    ultimateGoal=..., onlyAbstract=true)
    at /home/ivan/src/vcmi/code/AI/VCAI/VCAI.cpp:1894
#2  0x00007fffe1d9a681 in VCAI::striveToGoal (this=0x7fffbd15b508, 
    ultimateGoal=...) at /home/ivan/src/vcmi/code/AI/VCAI/VCAI.cpp:1873
#3  0x00007fffe1d90498 in VCAI::makeTurnInternal (this=0x7fffbd15b508)
    at /home/ivan/src/vcmi/code/AI/VCAI/VCAI.cpp:754
#4  0x00007fffe1d8faf7 in VCAI::makeTurn (this=0x7fffbd15b508)
    at /home/ivan/src/vcmi/code/AI/VCAI/VCAI.cpp:676

Copy zlib1.dll and rename the copy to zlib.dll.
Or download the updated package (I have added this file).

Please attach the client log and full stacktrace for all the threads. I will find what I need.
I am basically interested whether thread interrupt in the VCAI::finish() can be observed in CBattleCallback::sendRequest interruption point.

The bug goes like that. There are 2 threads in play:
Thread #1 CClient::run
Thread #2 VCAI::makeTurn for player blue

Server sends following messages:
A) it’s Blue’s turn
B) Player Blue loses game because it lost town 7 days ago
C) Its next player’s turn

Event sequence:
#1: Receives message A). Spawns thread #2.
#2: AI starts making turn. Blocks #1 from processing events (we don’t want gamstate to change when we make decisions)
#2: Selects a hero to have its path calculated.
#2: Unlocks #1 and waits till the hero is selected [and its path calculated].
#1: Receives message B). Calls VCAI::gameOver -> VCAI::finish. This interrupts thread #2: (it should unwind stack and close possibly soon — player is dead and should not think nor try any actions.) Then further messages are processed.
#2: CBattleCallback::sendRequest resumes. Interruption point I placed in the function should throw and make thread peacefully end. However, it is ignored, since TLS data can’t be obtained in VCMI_client (and its part CCallback). Thread goes on to calculate paths for the hero — but htere is no hero (it was removed along the player) and it crashes.

in all the campaigns I have just found a 2 bug.

Povelitel, so those 6 or so reports can be closed?

Tow, done, see attachment (26 KB)

Ivan, I think now it can be done with a clear conscience

Tow, I want to ask about testing whether it makes sense to do this? Mean crash turn on AI. If necessary I can find a lot of cases, it’s pretty easy. The main thing that someone had then repaired, and the efforts have not gone in vain.
I just do not want duplicates. Here for example, these files I do not know how to tell they were already on the ticket or not … or 1657 1658
games.rar (1.01 MB)
games2.rar (264 KB)

That’s why you should read AI logs to know what’s going on. Also, it’s nice to play with fog of war open.

Ugh, it went totally different path. (makeTurn was interrupted before it attempted selection and ended as expected)
Well… it seems there is another crashbug there.

It’s hard to make sense of this even for me, when I have debugger and have some knowledge of code. For you it is sometimes possible, sometimes not. The things you may try:

  1. reveal the map and try to observe whether AI attempts some similar behaviour when crash occurs
  2. turn on the AI output — Warmonger uploaded “Adventure AI trace” mod, you can download and enable it with Launcher.

Trying the point 2) shows that both crash from your post are about AI failing to handle goal “GET ARTIFACT OF TYPE”. So bugs are very likely duplicates and shouldn’t be reported separately.

EDIT: @Warmonger — wow, you said the same thing, just faster. :stuck_out_tongue:

Yes, I installed the “adventure AI trace”. Now I understand it is necessary to attach and logs.

Exploration map I did just flew AI I did not even see how it goes.

But you did not answer the main question for me. Whether to continue?
Or until enough (1527 1523 1518 1494… etс)

If you find a bug that is significantly different from already reported (or at least you are unable to tell that it is duplicate), report it.
However, if you are asking, if it makes sense to spend time on testing right now, I can’t answer. I myself won’t have much time and in the nearest future I won’t go over all bugs. If you have limited time, it might be better to wait until the issues currently reported are resolved and you won’t bump onto duplicates when running tests.
For the last months Warmonger took over the development of the AI and I hope he will be able to resolve recently reported issues.

By the way, I found strange bug.
When I try to enter Fortress, game crashes.
It works on 0.94b/c/d version.
Is it something with configs (I replaced existing files by new)?
Or buildings in Fortress are broken (I think of configs)?

All mods are turned off exept VCMI/WoG.

23:59:15 TRACE animation [2d64] - Button clicked at 608x535
23:59:15 TRACE animation [2d64] - Parent isclass CInfoWindow at 386x206
23:59:15 TRACE network [2d64] - Sending a request "struct SetSelection". It'll have an ID=2.
23:59:15 TRACE network [2d64] - Sending to server a pack of type struct SetSelection
23:59:15 TRACE network [1c8c] - 	received server message of type struct SetSelection, data: {CPack: type '514'}
23:59:15 TRACE network [1c8c] - 	Made first apply on cl
23:59:15 TRACE network [1c8c] - 	Applied on gs
23:59:15 TRACE network [1c8c] - 	Made second apply on cl
23:59:15 TRACE network [1c8c] - Listening... 
23:59:15 TRACE network [1c8c] - 	received server message of type struct PackageApplied, data: {CPack: type '94'}
23:59:15 TRACE network [1c8c] - 	Made first apply on cl
23:59:15 TRACE network [1c8c] - 	Applied on gs
23:59:15 TRACE network [1c8c] - 	Made second apply on cl
23:59:15 TRACE network [1c8c] - Listening... 
23:59:16 ERROR global [2d64] - Disaster happened.
23:59:16 ERROR global [2d64] - Reason: 0xc0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:6744A4C4
23:59:16 ERROR global [2d64] - Attempt to read from 0x00000000
23:59:16 ERROR global [2d64] - Thread ID: 11620 [11620]
23:59:16 ERROR global [2d64] - Crash info will be put in VCMI_client.exe_crashinfo.dmp
23:59:55 ERROR network [1c8c] - Lost connection to server, ending listening thread!


Please provide some means of reproducing this issue. Like map + instructions what to do to trigger crash.

  1. I turn off all mods except VCMI/WoG.
  2. defaultMods.json is standard from distributive
  3. I open provided map with Fortress selected (map is only for testing).
  4. When I try to open town, crash happens. In previous builds this didn’t happen.
    Forge Test2.h3m (9.36 KB)

Reproducible, failure to load bitmap from (lod?) archive, will fix.

I’ve got a problem with receiving 35 grand elves from the menu, when I’ve got choice to receive golems, grand elves or someone else. They are shown in my inventory (see screen) but don’t exist in battles. It’s definitely a regression.

Trying to replace my troops from one slot to another made vcmi crash.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffde89c700 (LWP 28856)]
CStackInstance::setArmyObj ([email protected]=0x0, [email protected]=0x0)
    at /build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/lib/CCreatureSet.cpp:591
591	/build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/lib/CCreatureSet.cpp: Нет такого файла или каталога.
(gdb) bt
#0  CStackInstance::setArmyObj ([email protected]=0x0, [email protected]=0x0)
    at /build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/lib/CCreatureSet.cpp:591
#1  0x00007ffff7a7d202 in CCreatureSet::detachStack (this=0x7fffcd5b4378, 
    at /build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/lib/CCreatureSet.cpp:390
#2  0x00007ffff79e1506 in SwapStacks::applyGs ([email protected]=0x7fffb4b98d30, 
    [email protected]=0x7fffcc3b6480)
    at /build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/lib/NetPacksLib.cpp:721
#3  0x00007ffff799879f in CApplyOnGS<SwapStacks>::applyOnGS (
    this=<optimized out>, gs=0x7fffcc3b6480, pack=0x7fffb4b98d30)
    at /build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/lib/CGameState.cpp:72
#4  0x00007ffff797e3f8 in CGameState::apply (this=0x7fffcc3b6480, 
    [email protected]=0x7fffb4b98d30)
    at /build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/lib/CGameState.cpp:2107
#5  0x00000000005be773 in CClient::handlePack ([email protected]=0x7fffcd06c340, 
    at /build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/client/Client.cpp:511
#6  0x00000000005beb20 in CClient::run (this=0x7fffcd06c340)
    at /build/buildd/vcmi-0.94+svn3438~ubuntu13.10.1/client/Client.cpp:150
#7  0x00007ffff6ddb94a in ?? ()
   from /usr/lib/x86_64-linux-gnu/
#8  0x00007ffff6bbaf6e in start_thread (arg=0x7fffde89c700)
    at pthread_create.c:311
---Type <return> to continue, or q <return> to quit---
#9  0x00007ffff40af9cd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

From menu? You mean campaign bonus selection screen? In this case - what campaign & what scenario causes this?
That’s yet another desync. Ouch.

Crash on moving troops is almost definitely result of those “ghost troops”

Restoration of erathia, United battlefront or something like this. Attached savegames.
Games.tar.gz (705 KB)