News window crashes when building has not been seen in the game

[wl-zocker]

Steps to reproduce:
- Open the attached savegame.
- Open the news window.
- The game crashes.

You are back in the main menu and get the following error message (last lines from stderr):
Fata exception: Could not find filename: could not find file or directory: global/militarysites/fortress.barbarians/../../../tribes/barbarians/fortress/fortress_i_00.png:0202c6
Game: Writing Preload Data ... took 124ms
Game: Writing Game Class Data ... took 1ms
Game: Writing Player Info ... took 13573ms
Game: Writing Map Data!
Writing Elemental Data ... took 1ms
 <some more stuff>
 Map_Saver::save() took 1291ms
Game: Writing Map Data took 1292ms
Game: Writing Player Economies Info ... took 35ms
Game: Writing Command Queue Data ... took 152ms
Game: Writing Interactive Player Data ... took 0ms
Game_Saver::save() took 15178ms
SaveHandler::save_game() took 15178ms
Object_Manager: ouch! remaining objects
lastserial: 20684

Unerwarteter Fehler im Spielverlauf
Could not find filename: could not find file or directory: global/militarysites/fortress.barbarians/../../../tribes/barbarians/fortress/fortress_i_00.png:0202c6

Please report this problem to help us improve Widelands. You will find related messages in the standard output (stdout.txt on Windows). You are using build bzr6890[trunk] (Release). Please add this information to your report.

Widelands attempts to create a savegame when errors occur during the game. It is often – though not always – possible to load it and continue playing.

The stderr shows several times "libpng warning: iCCP: known incorrect sRGB profile".

I was able to determine the following:
- The image of the building is in the specified folder (though I do not know what 0202c6 means).
- When you wait some time for another message to arrive, and then open the news windows, this message is shown. The fortress message is still not shown (the game crashes when you choose the message).
- When you move the main screen to a fortress and then open the news window, the message ("Your soldiers defeated the enemy at the fortress.") is shown correctly.

[Hans Joachim Desserud (hjd)]

Thanks for reporting this issue.

I believe the libpng warning message is unrelated, see bug 1195724 for more on those.

> The image of the building is in the specified folder (though I do not know what 0202c6 means).

When there's a problem in source files the dialog displays the line number the error occurs on after the filename (for instance foo.c:42). Maybe it becomes confused trying to find line numbers in an image file?

Actually, the save game currently crash while loading with the following error message:
 Writing Players Unseen Data ... took 437ms
 Writing Scripting Data ... PANIC: unprotected error in call to Lua API (attempt to persist a light C function (0x101d3eb))
Avbrutt (SIGABRT) (core dumped)

(Due to changes to the persistence layer and various other code changes, save game compatibilty might have some problems. A bit annoying though :/ ) I'll check if I can reproduce this issue though, either in a new game or by reverting to an older revison in order to load this...

[wl-zocker (wl-zocker)]

Reproduced in 6914, savegame attached. Just open the news window.
It did not happen when I conquered an Imperial barrier - therefore specific for the Barbarians or their fortress.
Just an idea: Might it be that the problem is that the fortress has several images because of the moving flag, while the barrier has not? Or is the problem the spritemap branch (bug 1121982) which has been merged in r6880? It is strange that I have never seen the bug before - the circumstances are not that unusual.

[Hans Joachim Desserud (hjd)]

I got the following backtrace when pressing "N" after loading the attached save game.

Thanks for finding and reporting all these weird edge-cases. :)

[SirVer (sirver)]

Should be fixed in r6928 for new games - the safegames will stay broken.

global/militarysites/fortress.barbarians/../../../tribes/barbarians/fortress/fortress_i_00.png:0202c6

This is the hash of the image that cannot be found, the :<hex number> at the end is the playercolor tint that is used for the derived image.

The problem here was the following: Building::send_message() asked for the representative_image() of the "idle" animation (which is the tinted image by the given player color) then created a rich text message that was referring to the hash of this building (a string) - which is valid at this point in time and until the game ends.

However on reload, send_message has not been called and so the derived image is not calculated and in the image cache - the lookup for the hash fails and the game tries to load the hash as a file from disk (which fails too). I solved this now by adding a method that asks for a representative image that can be loaded from disk at all times (in this case the non-tinted version of the building picture). A better fix would be to either recreate the message instead of saving the string to the safegame, adding support for representative images into the rich text renderer or instead of a string, save a Lua code string that is executed when the message should be displayed and will recreate the image.

Setting to fixcommitted for now, as the main problem should be solved. Can somebody check that?

[wl-zocker (wl-zocker)]

I cannot reproduce this issue in r6931 any more.

[wl-zocker (wl-zocker)]

Just a cross reference: Bug 978160 deals with the showing of player colors in messages, which is now no longer the case.