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...":https://support.plan.io/news/187
Actions
Send by e-mail Copy link

Bug #689225

closed

Settlers refuse to settle

Added by Joan Creus over 5 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
High
Assignee:
Jacob Nevins
Category:
Client
Sprint/Milestone:
2.5.12
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.

Files

Download all files
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

Actions
Actions
Copy link
 #1

Updated by Jacob Nevins over 5 years ago

Which client exactly is this?

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

Actions
Copy link
 #2

Updated by Joan Creus over 5 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

Actions
Copy link
 #3

Updated by Marko Lindqvist over 5 years ago

  • Sprint/Milestone changed from 2.6.0-beta1 to 2.6.0
Actions
Copy link
 #4

Updated by Jacob Nevins over 5 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

Actions
Copy link
 #5

Updated by Jacob Nevins over 5 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.

Actions
Copy link
 #6

Updated by Jacob Nevins almost 5 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.

Actions
Copy link
 #7

Updated by Jacob Nevins over 4 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.

Actions
Copy link
 #8

Updated by Anonymous over 4 years ago

Bug confirmed on gtk+:3.22.30

Actions
Copy link
 #9

Updated by Jacob Nevins over 3 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.)

Actions
Copy link
 #10

Updated by Jacob Nevins over 3 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.)

Actions
Copy link
 #11

Updated by Jacob Nevins over 3 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.

Actions
Copy link
 #13

Updated by Jacob Nevins over 3 years ago

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

Updated by Jacob Nevins over 3 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.
Actions
Copy link
 #15

Updated by Jacob Nevins over 3 years ago

  • Status changed from Resolved to Closed
Actions
Send by e-mail Copy link

Also available in: Atom PDF