road_program: Assertion `start.owner != nullptr || end.owner != nullptr' failed.

How big your RAM is? It is possible that there is some error in code, that shows when there is lack of free RAM. Than it can be hard to reproduce on other PC. Are you able to get gdb backtrace (if you have a linux)?

I can confirm this with the attached savegame. Tested two times with gdb and get the same crash:

widelands: /home/kaputtnik/Quellcode/widelands-repo/trunk/src/graphic/gl/road_program.cc:75: void RoadProgram::add_road(int, int, const FieldsToDraw::Field&, const FieldsToDraw::Field&, float, Widelands::RoadType, RoadProgram::Direction, uint32_t*): Assertion `start.owner != nullptr || end.owner != nullptr' failed.

Since i didn't build a road i guess the AI try's to build a road? Backtrace attached.

The crash happens randomly. Some times close after opening the save game, some times some minutes later.

I does not look as AI stuff, this is rather about drawing on screen.

Yes, i can trigger the bug with those steps:

1. Loading the save game
2. Increase Game speed
3. Just scroll around the map

The output and backtrace is always the same.

Hm, feels like an odd game speed (3,5,7,..) is needed.

scrolling around can be crucial here....

Definitely not memory shortage! I have 4 GB RAM and only 1.5 GB used when playing this.
Somehow the error slips into memory, I guess, probably by pointer error. The false data obviously can "hide" and produce an error later on.

I wonder that i did not run into this during playing also some big maps. So i guess this bug is only related to the attached savegame.

toptopple: Was this game saved intermediately with different widelands versions?

You are right, I also pondered why I appear to be the single one who encounters these funny error conditions. Sometimes I thought developer don't really play but develop. Anyway, there is higher probability these save-games grew up through various consecutive program versions as WL is regularly updated here via PPA and I tend to draw long games into multiple sessions which I play 2 hours in the evening maybe.

I like to raise the requirement that errors through different save-game versions must be prohibited by the program by recognising different save versions and suppressing incompatible loads. Is this possible to do?

We definitely don't want this error, so we will have to go hunting for it.

We already suppress incompatible loads, so this is a bug.

I have added some log output and found that the assert happens when the node 92,147 wants to be rendered with a road. Then i added code to prevent the assert condition by just returning, so the assert does not trigger and i could take a look what is there on the map. I also removed the FOW and found the situation shown in the attached screenshot.

The node 92,147 does not contain a road. Curiously the assert applies if this node has 'no owner' (!=nullptr), but the debug window shows "owner: 2"... whereas when examining this with gdb (through qtcreator), the node has no owner.

Another save game with the same crash.

When trying to have a look at the border area where the borders between the red, purple and black player meet

Posted on the forums: https://wl.widelands.org/forum/topic/2863/

Looks like this bug is not related to games saved with different versions: https://wl.widelands.org/forum/topic/2863/?page=1#post-20156

Another savegame: scroll north -> crash

Done some more digging - it seems to be a visibility problem when the road is owned by an enemy. If the attached savegame is run with the attached branch, it says:

   NOCOM drawing rn
   Road start 44, 7 - not owned
   Road end 45, 7 - not owned

Wait for Empire Glory to reach the coast and then explore with the bottom button towards the right, and the output goes away.

And there is definitely a functioning road at the buggy coordinates.

Found a previous attempt at a fix while working on the changelog:

https://code.launchpad.net/~widelands-dev/widelands/bug-1638394-render-road

I am committing the attached branch to trunk to see if the crash will occur again. Please reactivate this bug if it should happen again.

Fixed in build20-rc1