Project

Profile

Help

HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...

Bug #689225

Settlers refuse to settle

Added by Joan Creus about 4 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Client
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

I have found that some settlers refuse silently to build a city when given the "B" command. I have savegames if needed, but i've found an easy way to reproduce it.

Start a new game. Choose the first settler. Give the "B" command. When a city name is suggested, press Escape. Try to "B" again. Nothing happens, even in later turns.

A workaround is to quit the client, and start it again, so I guess it's a client bug.

26-689225-wip.patch (1.3 KB) 26-689225-wip.patch Proof of concept; not commit candidate Jacob Nevins, 2019-12-08 03:55 PM
m-input-dialog-close.patch (4.31 KB) m-input-dialog-close.patch commit candidate (master) Jacob Nevins, 2019-12-09 01:23 AM
30-26-input-dialog-close.patch (3.02 KB) 30-26-input-dialog-close.patch commit candidate (S3_0, S2_6) Jacob Nevins, 2019-12-09 01:24 AM
25-input-dialog-close.patch (1.73 KB) 25-input-dialog-close.patch commit candidate (S2_5) Jacob Nevins, 2019-12-09 01:24 AM

Related issues

Related to Freeciv - Bug #851568: Gtk3+: handle "close" signal in more GtkDialogs?New

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

History

#1 Updated by Jacob Nevins about 4 years ago

Which client exactly is this?

I've not managed to reproduce it with Gtk2, Gtk3, Qt, or SDL2.

#2 Updated by Joan Creus about 4 years ago

Jacob Nevins wrote:

Which client exactly is this?

I've not managed to reproduce it with Gtk2, Gtk3, Qt, or SDL2.

This the "About Freeciv":
This is Freeciv version 2.6.0-beta0 (beta version), gui-gtk-3.0 client.
Built against gtk+ 3.22.11, using 3.22.11
Built against glib 2.52.0, using 2.52.0

Running in a Gnome Ubuntu 17.04

#3 Updated by Marko Lindqvist about 4 years ago

  • Sprint/Milestone changed from 2.6.0-beta1 to 2.6.0

#4 Updated by Jacob Nevins about 4 years ago

Tried a little harder to reproduce with git commit:d2035ec4a01, built as follows on Xubuntu 14.04. No luck.

This is Freeciv version 2.6.0-beta0 (beta version), gui-gtk-3.0 client.
Built against gtk+ 3.10.8, using 3.10.8
Built against glib 2.40.2, using 2.40.2

#5 Updated by Jacob Nevins about 4 years ago

Seems correlated with Gtk3 version.

Could not reproduce with Windows Gtk3 msys1 build 2.6.0-beta0+29c84a15cb (which uses a very old Gtk3):
This is Freeciv version 2.6.0-beta0 (beta version), gui-gtk-3.0 client.
Built against gtk+ 3.8.2, using 3.8.2
Built against glib 2.36.1, using 2.36.1

But I could reproduce with Windows Gtk3 msys2 build 2.6.0-beta0+c8cad4d8dd (which uses a newer Gtk3):
This is Freeciv version 2.6.0-beta0-msys2 (beta version), gui-gtk-3.0 client.
Built against gtk+ 3.22.16, using 3.22.16
Built against glib 2.52.3, using 2.52.3

I found that the issue was specific to pressing 'Esc'. Pressing the 'Cancel' button with the mouse didn't break things.

#6 Updated by Jacob Nevins over 3 years ago

  • Priority changed from Normal to High

Unsurprisingly, this is still there in 2.6.0-beta3. (Unsurprising since none of the Gtk3 versions have changed.)

Can't reproduce in the shipping msys1 build:

This is Freeciv version 2.6.0-beta3 (beta version), gui-gtk-3.0 client.
Built against gtk+ 3.8.2, using 3.8.2
Built against glib 2.36.1, using 2.36.1

nor in my own build on my elderly Linux system:

This is Freeciv version 2.6.0-beta3 (beta version), gui-gtk-3.0 client.
Built against gtk+ 3.10.8, using 3.10.8
Built against glib 2.40.2, using 2.40.2

Can reproduce in the msys2 32-bit Gtk3 build (under Wine):

This is Freeciv version 2.6.0-beta3-msys2 (beta version), gui-gtk-3.0 client.
Built against gtk+ 3.22.16, using 3.22.16
Built against glib 2.52.3, using 2.52.3

and in the 32-bit Gtk3.22 msys2 build:

This is Freeciv version 2.6.0-beta3-msys2 (beta version), gui-gtk-3.22 client.
Built against gtk+ 3.22.16, using 3.22.16
Built against glib 2.52.3, using 2.52.3

and in the 64-bit Gtk3 msys2 build:

This is Freeciv version 2.6.0-beta3-msys2 (beta version), gui-gtk-3.0 client.
Built against gtk+ 3.22.16, using 3.22.16
Built against glib 2.52.3, using 2.52.3

This pattern is entirely consistent with the previous behaviour.

This is quite serious -- anyone building the recommended client on up-to-date Linux is likely to encounter it. It also blocks our plans to move to msys2 in a future release.

Unfortunately, I'm not well set up to debug it.

#7 Updated by Jacob Nevins over 3 years ago

  • Sprint/Milestone changed from 2.6.0 to 2.6.1

Can someone with the ability to build with more recent Gtk3 than me investigate this? It is likely to be a serious problem once 2.6.x hits e.g. Debian.

#8 Updated by Anonymous over 3 years ago

Bug confirmed on gtk+:3.22.30

#9 Updated by Jacob Nevins almost 2 years ago

This old bug is still present in S2_6 d46b64fa24 with Gtk3 and Gtk3.22 clients on Debian buster:

This is Freeciv version 2.6.0+ (adb48c2bbd), gui-gtk-3.0 client.
Built against gtk+ 3.24.5, using 3.24.5
Built against glib 2.58.3, using 2.58.3

This is Freeciv version 2.6.0+ (adb48c2bbd), gui-gtk-3.22 client.
Built against gtk+ 3.24.5, using 3.24.5
Built against glib 2.58.3, using 2.58.3

(Now I can reproduce it in an environment I can debug, I might actually be able to look at it.)

#10 Updated by Jacob Nevins almost 2 years ago

When there's no response, it's because punit->client.asking_city_name is TRUE; this causes handle_city_name_suggestion_info() to silently do nothing. (That function only looks for units with this flag on the same tile; perhaps intended to handle sending multiple settlers to a site and having the one that gets there first win?)

It looks like pressing Esc in new Gtk3.x somehow bypasses name_new_city_popup_callback(), which should clear that flag. (It's not that the callback is being called with some unhandled response value.)

(Tangent: I wonder if we should make the city name suggestion dialog a bit like the caravan actions etc dialogs, that it pops up when the unit takes focus and you can "wait" to defer it, etc. But that's not the fix for this bug.)

#11 Updated by Jacob Nevins almost 2 years ago

This is what we're missing:

https://developer.gnome.org/gtk3/stable/GtkDialog.html#GtkDialog-close

Attached in a work-in-progress patch (S2_6 Gtk3.22) which fixes it for me. I'll tidy it up later.

Bug also affects S2_5 Gtk3.

#13 Updated by Jacob Nevins almost 2 years ago

  • Related to Bug #851568: Gtk3+: handle "close" signal in more GtkDialogs? added

#14 Updated by Jacob Nevins almost 2 years ago

input_dialog is used in two other places (which are thus also fixed by this patch):
  • "Rename City" UI. And indeed, pressing Esc leads to the following message when the relevant city dialog is closed:
    Gtk-CRITICAL **: 01:07:20.183: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed
  • CMA preset UI. Not sure if it causes trouble there.

#15 Updated by Jacob Nevins almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF