Assertion failed in units/map.hpp:211 when trying to load a specific save file

[Dugy]

Game and System Information

• Replicable on various 1.14 versions and on multiple OS, I am sure it happens with wesnoth 1.14.9 on Ubuntu, downloaded from the Ubuntu repository

Bug description

Assertion failed, seems to be an attempt to dereference an invalid iterator at units/map.hpp:211.

/build/wesnoth-1.14-hyzHmG/wesnoth-1.14-1.14.9/src/units/map.hpp:211: unit_map::iterator_base<iter_types>::pointer unit_map::iterator_base<iter_types>::operator->() const [with iter_types = unit_map::standard_iter_types; unit_map::iterator_base<iter_types>::pointer = boost::intrusive_ptr<unit>; typename iter_types::value_type = unit]: Assertion `valid()' failed.

To Reproduce

Steps to reproduce the behavior:

1. Load this save file (you need to have the Legend of the Invincibles add-on installed)
2. Click through the map (one click on next or skip is enough)
3. The game crashes

[gfgtdf]

so i tried to reproduce on master (1.15.3+dev) and got no assertion failure. Can you consitently reproduce this error on 1.14.13 ?

[Dugy]

Yes. Reliable instant crash. Also the guy who sent it to me. I even have a save file from another scenario where progressing into this scenario causes the crash.

[gfgtdf]

hmm okay so i unfortunately still didn't figure out yet how to debug wesnoth on this new linux computer, but i think anyone who is abel to create a stacktrace should be to fix this easily.

[Dugy]

If you have compiled it yourself (and thus have the debugging symbols), the easiest way to do it is to simply launch it in valgrind (valgrind can be installed from the apt repo).

valgrind wesnoth

Assuming that the command wesnoth launches the right executable. It will run slowly, but you will get the stacktrace and some possibly useful additional info, like undefined behaviour messages.

I am on a new computer and I don't have the compilation of wesnoth set up, so I don't have the debugging symbols.

[Pentarctagon]

While not applicable here, for future reference, debug executables for Linux, macOS, and Windows are available at https://sourceforge.net/projects/bfw-travis-upload/files/master/ (the ones with debug in the folder name). These are uploaded from each travis job that runs, assuming it's successful.

This functionality wasn't/isn't likely to be backported to 1.14, but will carry over to 1.16 and future releases.

[gfgtdf]

So instead of debuggin it i have looked into the safeile/scenario: the erro seems to be related to the fact that you have two unit with the same id "Lethalia_evil" and are doing something in "unit placed" events in the DISABLE_UPKEEP macro.

[gfgtdf]

So even if we fix this error, you code will probably not work since it has two units with the same id.

[gfgtdf]

reepoen for backport

[Dugy]

So even if we fix this error, you code will probably not work since it has two units with the same id.

Duplicate units is a problem that can happen quite easily and could usually be spotted quite easily. If it triggers a crash, it's difficult to find without having any previous clues what could be wrong.

And as far as I know, it's said that bad scenario code should not cause crashes.

[gfgtdf]

. If it triggers a crash

It doesn't, (the actual bug was in some code that called fire_event, see the commit mesage above)., but it makes the code behave unexpectedly, At some point the engine will probably remove one of these units because some code is called that assumes the ids are unique.

[Dugy]

Aha, so it was a real bug that happened to manifest because of my stupid code.

[gfgtdf]

yes