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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
