Project

General

Profile

Bug #689225

Settlers refuse to settle

Added by Joan Creus about 3 years ago. Updated 10 months ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Client
Target version:
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

History

#1 Updated by Jacob Nevins about 3 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 3 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 3 years ago

  • Target version changed from 2.6.0-beta1 to 2.6.0

#4 Updated by Jacob Nevins about 3 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 3 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 2 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 about 2 years ago

  • Target version 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 about 2 years ago

Bug confirmed on gtk+:3.22.30

#9 Updated by Jacob Nevins 10 months 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 10 months 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 10 months 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 10 months ago

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

#14 Updated by Jacob Nevins 10 months 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 10 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF