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