Incidencia #43724

Segfault with cyclic requirements in self-provided goods

Abrir Fecha: 2022-01-28 23:33 Última actualización: 2022-02-04 09:30

Informador:
Propietario:
(Ninguno)
Tipo:
Estado:
Open
Componente:
Hito:
Prioridad:
5 - Medium
Gravedad:
5 - Medium
Resolución:
Ninguno
Fichero:
Ninguno

Details

With the self-provided goods introduced in #43532, infinite recursion is possible via is_req_active -> is_goods_type_in_range -> goods_can_be_provided -> are_reqs_active -> is_req_active if ruleset authors include cyclic dependencies between self-provided goods. This should probably be caught with sanity checks when loading the ruleset rather than crashing.

Ticket History (3/4 Histories)

2022-01-28 23:33 Updated by: alienvalkyrie
  • New Ticket "Segfault with cyclic requirements in self-provided goods" created
2022-01-28 23:48 Updated by: alienvalkyrie
Comentario

Potential added complexity: If a ruleset author wants goods that are already mutually exclusive due to other requirements (so the infinite recursion can never happen), but also wants importing one of them to disable the other, e.g.

[goods_wetness]
name = _("Wetness")
reqs =
    { "type",         "name",    "range",    "present"
      "TerrainClass", "Oceanic", "Adjacent", TRUE
      "Good",         "Dryness", "City",     FALSE
    }
flags = "Self-Provided"

[goods_dryness]
name = _("Dryness")
reqs =
    { "type",         "name",    "range",    "present"
      "TerrainClass", "Oceanic", "Adjacent", FALSE
      "Good",         "Wetness", "City",     FALSE
    }
flags = "Self-Provided"
i.e. a city can only export authentic Wetness when it's next to the ocean and doesn't import Dryness, and it can only export authentic Dryness when it's landlocked and doesn't import Wetness.

Allowing this would make load-time sanity checks more complicated.

2022-01-29 17:16 Updated by: cazfi
Comentario

Yup, I'm quite annoyed with myself. Multiple time I've been looking in to need of Self-Provided goods, to then realize that it would cause recursion problems and reject the idea. Forget that in a couple of months and start from the beginning...

One possible solution still is that we simple revert Self-Provided goods. We need at least to make a decision about that before S3_2 d3f.

This is not the first recursive requirement (though I don't remember the other one(s) from the top of my head). The sanity check should be generic enough to catch any complex infinite recursion over different requirement types (Good 1 requirement -> Type B requirement -> Good 2 requirement -> Type C requirement -> Good 1 requirement)

2022-02-04 09:30 Updated by: alienvalkyrie
Comentario

Reply To cazfi

This is not the first recursive requirement (though I don't remember the other one(s) from the top of my head). The sanity check should be generic enough to catch any complex infinite recursion over different requirement types (Good 1 requirement -> Type B requirement -> Good 2 requirement -> Type C requirement -> Good 1 requirement)

Even if it is generic enough, that only really works fine for the case where at every step along that chain, the relevant requirement (whether present or not) can only be fulfilled in one specific way – in more general cases (like the example above) the sanity check would have to realize, based on the contradictory terrain class requirements, that infinite recursion isn't possible... until we evaluate against something where the terrain class requirements become TRI_MAYBE and we have to recurse into the goods requirement anyway. Hm.

Point is, if we want to make this sanity check without being overly restrictive, it'd have to explore a (possibly very large) tree of ways that certain requirements (particularly negated ones) could be fulfilled, while keeping in mind all the facts that already have to be given to even reach that test. I'm not sure that's such a sensible thing to do.

So really, the two options we have (as far as I can tell) are

  • making recursive requirements statically impossible (in particular, reverting Self-Provided goods and replacing them with some other solution), or
  • adding infinite-recursion-detection to the requirement checker (e.g. building a list of everything that's currently being evaluated in is_req_active)

The latter would also mean we'd have to decide on what to do in case of infinite recursion – in particular, when something negatively depends on itself.

Attachment File List

No attachments

Editar

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Entrar