Stefan Berger wrote:
> If it's not 0, then you must have one of these two envvars
set:
>
> test -n "$CCC_ANALYZER_ANALYSIS$COVERITY_BUILD_COMMAND" && echo
oops
got 'oops' here.
That is surprising (esp. since your definition of STATIC_ANALYSIS was 0).
You get that on the command line?
Which of those two variables is defined for you?
And to what?
echo "$CCC_ANALYZER_ANALYSIS"
echo "$COVERITY_BUILD_COMMAND"
If you confirm, I may have to adjust the configure-time
test to be less prone to false positive.
> How is sa_assert defined for you?
>
> $ grep -C3 sa_assert src/internal.h
> # if STATIC_ANALYSIS
> # undef NDEBUG /* Don't let a prior NDEBUG definition cause trouble. */
> # include <assert.h>
> # define sa_assert(expr) assert (expr)
> # else
> # define sa_assert(expr) /* empty */
> # endif
>
> With those, the net result in your file should be that
> sa_assert is a no-op.
Yes, I agree. My understanding also.
> If you're still convinced that the segfault is due to that use
> of sa_assert, please send me preprocessed output for that file, i.e.,
>
> cd src
> f=nwfilter_ebiptables_driver
> touch nwfilter/$f.c
> la=libvirt_driver_nwfilter_la
> lo=$la-$f.lo
> make AM_CPPFLAGS='-E -dD' $lo
> mv .libs/$la-$f.o $f.i
>
> The cpp-preprocessed output is now in
>
> src/nwfilter_ebiptables_driver.i
>
> You should be able to see that sa_assert expands to nothing:
>
> $ grep sa_assert $f.i
> #define sa_assert(expr)
Well, not quite true. I see the lonely semicolon there that's the remainder from
sa_assert(); -> one would have to write sa_assert(), which isn't nice, either...
if (ebiptablesExecCLI(&buf, &cli_status) || cli_status != 0)
goto tear_down_tmpebchains;
for (i = 0; i < nruleInstances; i++)
;
switch (inst[i]->ruleType) {
Right. It's obvious, once you notice the missing curly brace.