Bug #1827
closedSegmentation fault from mouse click in gotodlg.cpp
0%
Description
my mouse clicks are messy, so I'm not sure whether a city was selected or not.
Looking at the coredump, it is clear that `game_city_by_number(city_id)` returns nullptr.
The `city_id` seemed to be out of range.
Files
| clipboard-202512200001-yvmpo.png (261 KB) clipboard-202512200001-yvmpo.png | coredump in debugger | ||
| 1827.patch (824 Bytes) 1827.patch | |||
| 1827.v2.patch (1.06 KB) 1827.v2.patch |
Updated by Marko Lindqvist 12 days ago
John Robertson wrote:
Looking at the coredump, it is clear that `game_city_by_number(city_id)` returns nullptr.
The `city_id` seemed to be out of range.
Even if that was not what happened to you, I think it's quite possible that a city gets destroyed while the dialog is open, leading to such a segfault.
Updated by Marko Lindqvist 12 days ago
- Status changed from New to In Review
- Assignee set to Marko Lindqvist
- Target version set to 3.2.2
Updated by John Robertson 12 days ago
Marko Lindqvist wrote in #note-2:
John Robertson wrote:
Looking at the coredump, it is clear that `game_city_by_number(city_id)` returns nullptr.
The `city_id` seemed to be out of range.
Even if that was not what happened to you, I think it's quite possible that a city gets destroyed while the dialog is open, leading to such a segfault.
Yes, I have seen a conquered enemy city stay in the gotodlg list, not updated. E.g. the city doesn't switch sides, or a deleted city remains in the list until the next refresh.
Updated by John Robertson 12 days ago
Maybe the return should include a list refreash.
Updated by Marko Lindqvist 11 days ago
At least for the 3.2.2 release coming out soon (-> with limited testing time left) I still plan to go with the original minimal-risk patch. We can revisit this in the full 3.2.3 cycle.