Dear Genodians
I'm lost and would appreciate some inspiration on how to further debug a problem in a scenario that is similar to `run/depot_query`.
My scenario seems to work fine on x86_64 but on 32-bit ARM (base-linux) the `depot_query` component segfaults. Well, it doesn't always segfault but it seems to depend either on the `depot.tar` or the `deploy.config` or both. However, the `deploy.config` and `depot.tar` don't need to change much: only the depot user or the package version may vary.
The segfault occurs in `Depot_query::Main::_query_blueprint(...)` when accessing the `node` parameter that has been instantiated by the class `File_content` when calling the lambda.
I also need to mention that the segfault reproducibly occurs at the same "to be deployed" runtime (pkg/chroot) - at least for a given `depot.tar` / `deploy.config`. Other, much larger runtime files (~9k) have been processed successfully prior that in `pkg/chroot`.
I'm aware that this is a rather vague description and therefore tried to provide a modified the `run/depot_query.run` so it uses my `deploy.config` and `depot.tar`. But no luck, I can't reproduce the problem this way...
Has anyone an idea what could possibly lead to a "corrupt" instance of `Xml_node`? Or how to test hypotheses like a stack overflow, ...?
Thanks, Roman