bugFreeciv - Bugs: bug #21116, National borders display...

 
 
Show feedback again

bug #21116: National borders display disappeared from client

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sat 07 Sep 2013 05:59:25 PM UTC  
 
Category: client-gtk-2.0Severity: 3 - Normal
Priority: 5 - NormalStatus: Fixed
Assigned to: Jacob Nevins <jtn>Open/Closed: Closed
Release: 2.4.0-RC1Operating System: Microsoft Windows
Planned Release: 2.4.1,2.5.0,2.6.0

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 08 Nov 2013 11:40:05 PM UTC, SVN revision 23711:

In tileset_free(), player color sprites from the global tileset were
freed rather than the specified one. This caused player color sprites
(national borders and unit backgrounds) to stop working when the local
options dialog was popped up for the first time.

Reported by Christian Knoke (chrisk AT cknoke.de) and myself.

See gna bug #21116 and gna bug #21151.

(Browse SVN revision 23711)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Fri 08 Nov 2013 11:38:08 PM UTC, SVN revision 23709:

In tileset_free(), player color sprites from the global tileset were
freed rather than the specified one. This caused player color sprites
(national borders and unit backgrounds) to stop working when the local
options dialog was popped up for the first time.

Reported by Christian Knoke (chrisk AT cknoke.de) and myself.

See gna bug #21116 and gna bug #21151.

(Browse SVN revision 23709)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Fri 08 Nov 2013 11:34:27 PM UTC, SVN revision 23707:

In tileset_free(), player color sprites from the global tileset were
freed rather than the specified one. This caused player color sprites
(national borders and unit backgrounds) to stop working when the local
options dialog was popped up for the first time.

Reported by Christian Knoke (chrisk AT cknoke.de) and myself.

See gna bug #21116 and gna bug #21151.

(Browse SVN revision 23707)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sun 03 Nov 2013 03:44:37 PM UTC, comment #11:

> As I said, I had been switching tilesets a bit earlier.

...and the only way to do that is by bringing up the local settings dialog, so I think this was probably the cause. (For once it's not the fault of loading a new tileset in midgame, which is usually troublesome.)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sun 03 Nov 2013 03:30:27 PM UTC, comment #10:

Found a plausible cause related to the local settings dialog -- see bug #21151 comment 6. Don't have time right now to submit a patch.

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sun 03 Nov 2013 03:00:49 PM UTC, comment #9:

In bug #21151, merely opening the local settings dialog (without touching anything) causes immediate trouble... and now I check, it causes the borders to disappear too (although it might not be evident until the mapview is refreshed).

This is true with both 2.4.0 and S2_4 r23683 (after bug #21231 fix).

Given the potential for refresh delays breaking reporters' idea of what it's correlated with, I think we may have a winner?

(No idea yet why opening the local settings dialog should have that effect.)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sun 03 Nov 2013 02:31:22 PM UTC, comment #8:

> if someone called tileset_player_free() while a player was
> still active.


As I said, I had been switching tilesets a bit earlier. It's very likely that it's important factor here. Also, I wonder if fix of bug #21231 might affect this behavior too.

Marko Lindqvist <cazfi>
Project Administrator
Sun 03 Nov 2013 01:51:28 PM UTC, comment #7:

> 1: in fill_grid_sprite_array() [client/tilespec.c::4561]: assertion 't->sprites.player[plrid].grid_borders [pedge->type][0] != NULL' failed.

This is interesting. Certainly if this condition has occurred, I think borders won't be drawn but most other stuff will.

The only way I've spotted that we can end up in this situation is if someone called tileset_player_free() while a player was still active.
(Or if in tileset.c someone ended up referring to a slot -- plrid -- that didn't correspond to an active player, but I don't see how that can happen since everything in tileset.c goes through a struct player *.)

Also, interestingly, Christian Knoke reports the following assertion failure in bug #21151 (may be unrelated to main topic):

> 1: in fill_sprite_array() [tilespec.c::4554]: assertion 't->sprites.player[player_index(owner)].background != NULL' failed.

Which, again, would be explained by tileset_player_free() being called at the wrong time. However, in that case it might be a sequencing problem while removing a player, whereas here the player whose borders disappeared definitely continues to exist.
(I'm a bit worried by handle_player_remove() calling tileset_player_free() when not all of the player's cities/units might yet have been removed from the map, but probably not relevant to this ticket.)

Is it possible that a player was removed at the time borders disappeared in your game? I'm wondering about tileset_player_free() somehow hitting the wrong players. (Although I don't see how it can have happened in my single-player game; even if a player was killed in-game, that shouldn't trigger PACKET_PLAYER_REMOVE. So I'm clutching at straws a bit here.)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Thu 26 Sep 2013 03:39:10 PM UTC, comment #6:

My current game:

- Border drawing stopped mid-turn, not turn-change (I did my part of the turn hours ago, and now when I were checking some things on the client, borders were no longer drawn)
- I were testing theme changes a bit earlier (could be that no borders have been drawn since then)
- There still is some parts of the borders visible that have only moved around the screen, tiles not redrawn
- Middle-mouse tooltip shows tile ownership to still be correct
- Toggling "National Borders" off from view menu removed remaining borders, toggling them back on did nothing (still not visible)
- Nations -dialog (even when opened anew) shows correct player colour for me

Oh... the console I've started client with outputs errors all the time:

1: in fill_grid_sprite_array() [client/tilespec.c::4561]: assertion 't->sprites.player[plrid].grid_borders [pedge->type][0] != NULL' failed.
2: Backtrace:
2: 0: ./client/freeciv-gtk2() [0x5e0f0d]
2: 1: ./client/freeciv-gtk2(vdo_log+0x89) [0x5e5ba9]
2: 2: ./client/freeciv-gtk2(do_log+0x7d) [0x5e5c5d]
2: 3: ./client/freeciv-gtk2(fc_assert_fail+0x9f) [0x5e5e8f]
2: 4: ./client/freeciv-gtk2() [0x4b58ca]
2: 5: ./client/freeciv-gtk2(fill_sprite_array+0x7f0) [0x4bcb60]
2: 6: ./client/freeciv-gtk2(put_one_element+0x56) [0x4910f6]
2: 7: ./client/freeciv-gtk2(update_map_canvas+0x582) [0x494cc2]
2: 8: ./client/freeciv-gtk2(unqueue_mapview_updates+0x401) [0x495d41]
2: 9: ./client/freeciv-gtk2() [0x44a00a]
2: 10: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x146) [0x7f046b217ea6]
2: 11: /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x481f8) [0x7f046b2181f8]
2: 12: /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x6a) [0x7f046b2185fa]
2: 13: /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xa7) [0x7f046d0e8257]
2: 14: ./client/freeciv-gtk2(ui_main+0x529) [0x44cf29]
2: 15: ./client/freeciv-gtk2(client_main+0x2ff) [0x472caf]
2: 16: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f046aa1b995]
2: 17: ./client/freeciv-gtk2() [0x449d5e]

Marko Lindqvist <cazfi>
Project Administrator
Sat 21 Sep 2013 08:36:31 AM UTC, comment #5:

I have seen this as well as Jacob describes. T'was loaded from savegame. Dunno i will look, can a -d 3 log help?

svn 2.4.0 rev. 23370 gtk2 on linux

chrisk

Anonymous
Thu 19 Sep 2013 10:53:48 PM UTC, comment #4:

> it never happens at the start, alway after playing a few
> more turns from the savegame.


Does the "always" mean there's a savegame from which this can be reliably reproduced, or just that when it happens, it's always a couple of turns to game from the savegame loading?

Marko Lindqvist <cazfi>
Project Administrator
Thu 19 Sep 2013 10:38:45 PM UTC, comment #3:

Someone else on IRC reports having seen this (no further info on the questions posed here as I missed them):

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 07 Sep 2013 06:20:38 PM UTC, comment #2:

> Did you test if they were missing on one screen draw only

I didn't test with that in mind, but I played on for a number of turns, which I'm pretty sure entailed scrolling the map around a fair bit, so the no-drawn-borders state seemed pretty robust.

> Did you checked with middle-clicking tiles that each tile was
> owned by who it was supposed to?

That would have been cunning. Sadly I didn't think of it.

(I believe I founded some cities in the intervening period, so the borders will have changed.)

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.
Sat 07 Sep 2013 06:14:14 PM UTC, comment #1:

Did you test if they were missing on one screen draw only, or was client redrawing view (for example after you looked another part of the map and then centered back to your area - scrolling so that area is all the time within view is not enough) consistently without borders?

Did you checked with middle-clicking tiles that each tile was owned by who it was supposed to? (To tell if bug is in assignment of tile owners, or in that border is not drawn between different owner tiles)

Marko Lindqvist <cazfi>
Project Administrator
Sat 07 Sep 2013 05:59:25 PM UTC, original submission:

Another irreproducible result:

I was playing a single-player test game on Windows 2.4.0-RC1, and at some point the display of my national borders (which had been there at the start) just disappeared from the main map entirely.

Repeatedly toggling the "national borders" option on the View menu made no difference. Connecting another client as a global observer, the borders were displayed in that client.

Reloading the game, the borders were back (this is admittedly after fiddling with various view options, but not between quitting the faulty client and starting again).

Savegame attached, FWIW. This is some turns after it happened; I believe it was a turn when a city grew from size 1 to size 2.

Jacob Nevins <jtn>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #19329:  trunk-S2_5-S2_4-settingsdlg-free-playercolor.patch added by jtn (1002B - text/x-diff - trunk/S2_5/S2_4 r23696)
file #18915:  nonationalborders.sav.bz2 added by jtn (18kB - application/x-bzip - 2.4.0-RC1 national borders disappeared)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 08 Nov 2013 11:59:27 PM UTCjtnOpen/ClosedOpen=>Closed
    Fri 08 Nov 2013 11:59:26 PM UTCjtnStatusReady For Test=>Fixed
    Thu 07 Nov 2013 12:35:18 AM UTCjtnAttached File-=>Added trunk-S2_5-S2_4-settingsdlg-free-playercolor.patch, #19329
      StatusNone=>Ready For Test
      Assigned toNone=>jtn
    Sun 03 Nov 2013 12:06:23 PM UTCjtnPlanned Release=>2.4.1,2.5.0,2.6.0
    Thu 24 Oct 2013 11:37:10 PM UTCcazfiSummaryNational borders display disappeared from client on turn change=>National borders display disappeared from client
    Sat 07 Sep 2013 05:59:46 PM UTCjtnSummaryNational borders display disappeared from client=>National borders display disappeared from client on turn change
    Sat 07 Sep 2013 05:59:25 PM UTCjtnAttached File-=>Added nonationalborders.sav.bz2, #18915
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup