On 9/20/21 7:21 PM, Tim Wiederhake wrote:
> This is an alternative to
>
https://listman.redhat.com/archives/libvir-list/2021-September/msg00522.html.
>
> When libvirt is build:
> * with sanitizers enabled,
> * buildtype explicitly set to "debug",
> * on clang,
>
> the build fails with:
>
> ../src/conf/nwfilter_conf.c:2190:1: error: stack frame size of 10616
> bytes in function 'virNWFilterRuleDefFixup'
[-Werror,-Wframe-larger-than=]
> virNWFilterRuleDefFixup(virNWFilterRuleDef *rule)
> ^
> 1 error generated.
>
> ../src/conf/domain_conf.c:19514:1: error: stack frame size of 8312
> bytes in function 'virDomainDefParseXML' [-Werror,-Wframe-larger-than=]
> virDomainDefParseXML(xmlXPathContextPtr ctxt,
> ^
> 1 error generated.
>
> Note that this does not happen when "-Dbuildtype" is not specified, even
> though "debug" is the default build type.
>
> The patches in this series happen to make these errors go away.
>
> Regards,
> Tim
>
> Tim Wiederhake (2):
> virDomainDefParseXML: Use automatic memory management
> virNWFilterRuleDefFixup: Replace macro with function
>
> src/conf/domain_conf.c | 208 ++++++++++++++--------------
> src/conf/nwfilter_conf.c | 284 ++++++++++++++++++++-------------------
> 2 files changed, 245 insertions(+), 247 deletions(-)
>
Frankly, I don't understand how either of patches can size the frame
down, but they make sense regardless.
The first patch is fine, but I don't think the second is. It introduces
countless more pointless fnuction calls when a macro suffices.
We just need to increase the stack frame check limit for instrumented
builds. Enforcing stack frame only makes sense on normal builds when
stack usage is determinstic
Regards,
Daniel
--
|: