Hello Norman,
There's no segfault if I either completely remove the empty `<config/>`-node or replace it with `<config></config>`.
intuitively, this looks related, indeed. But given the code, I'm unable to immediately spot the same pattern. The '_apply_blueprint' does not parse the <config> node after all. It merely copies the compounding <runtime> node as is (via 'Xml_node::with_raw_node').
My conclusion was indeed premature. Using another depot user with different archive versions, the segfault happens at a different package - no matter the `<config>`-node in pkg/chroot. At least in this particular case it *seems* to be related to the file size of the runtime file. If this file happens to be between 817 and 832 bytes, it fails. There's no problem it the file is bigger or smaller (tested with +/- ~5 bytes).
- Does the problem occur on any kernel/architecture combination other than base-linux on 32-bit ARM?
It does not occur on base-linux/x86_64. Because the scenario is rather complex it cannot be run easily on other kernel/architecture combinations.
- Does it occur when using the original tool chain?
For the ARM target and base-linux where the error happens I cannot use the original tool chain. For x86_64 and base-linux I use the original toolchain.
I tried run/depot_query with my depot.tar on base-hw on 32-bit ARM (zynq/qemu). It successfully executes.
So as far as I know it doesn't occur when using the original tool chain.
Do you have an example scenario that I could use for reproducing the problem at hand? I'd very much appreciate that.
Unfortunately not. I'm aware that under this circumstances your hands are pretty much tied. I keep you posted if I have more concise information either about the source of the problem or how to reproduce it in a "generally available setting".
Thanks for your support so far!
Cheers, Roman