Bug #1954
openSIGSEGV at startup
0%
Description
Latest dev [Qt]
Race condition `real_menus_update()` is sometimes called before `real_menus_init()`.
For the Qt client this results in accessing an uninitialized `multiplayer_menu` variable.
Files
Updated by John Robertson 8 months ago
This could also be cause from a delay in the loading of the ruleset (e.g. `!game.client.ruleset_ready`).
If `real_menu_init() returns without initializing, because the ruleset took too long to load, is it ever called again?
Updated by John Robertson 8 months ago
- File 1954.patch 1954.patch added
I tend to startup the server and client at the same time. I think `real_menus_init()` returns because the ruleset has not yet been loaded, causing the `multiplayer_menu` variable to never become initialized.
Updated by John Robertson 8 months ago
- File 1954.v2.patch 1954.v2.patch added
Reduced, but not perfect, risk.
Updated by John Robertson 8 months ago
- File 1954.v3.patch 1954.v3.patch added
Perfectly remove the SIGSEGV, at the sacrifice of the menus. The menus are constantly rebuilt/updated, so eventually, the `real_menus_init()` should succeed.
Updated by John Robertson 8 months ago

Before fix
`multiplayer_menu` is NULL in `real_menus_update()` if `real_menus_init()` exits because the server ruleset is not ready.
Updated by Marko Lindqvist 13 days ago
John Robertson wrote in #note-2:
I tend to startup the server and client at the same time. I think `real_menus_init()` returns because the ruleset has not yet been loaded, causing the `multiplayer_menu` variable to never become initialized.
That makes no sense. Server loads rulesets before accepting any client connections, so server start time shouldn't have any role in this.
However, it's possible that client tries to use menus before it has received rulesets from the server. We've had bugs of that type in the past. There's mystery, though, in why you are seeing this and others (at least myself) are not. One would assume it to be deterministic.