depot_query: segmentation in _query_blueprint?

Roman Iten roman.iten at gapfruit.com
Thu Mar 26 15:08:01 CET 2020


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20200326/ecd61ec8/attachment.sig>


More information about the users mailing list