Open MartinWehking opened 2 years ago
Thanks for flagging this!
We will not have time to address this for this year's SVCOMP, moving to 2024.
Goblint also crashes with an IncompatibleIkinds
exception on the sqlite-amalgamation in some configuration.
Do you have a line number here? I think debugging the amalgamation makes more sense than these LDV programs that are dubious anyway.
Do you have a line number here?
No, not yet, this was run on a version of Goblint that did not print the lint number. I now started a run with the current master merged, so that hopefullly yields a line number.
Now with #931 merged, there is a whole stack of line numbers:
Goblint command:
./analyzer/goblint --conf ./analyzer/conf/custom/sqlite-ctx-sens-no-priv.json ./bench/scripts/incremental/benchmarking/result_efficiency/process0/sqlite/sqlite3.c ./bench/scripts/incremental/benchmarking/result_efficiency/process0/sqlite/sqlite3.h ./bench/scripts/incremental/benchmarking/result_efficiency/process0/sqlite/sqlite3ext.h ./bench/scripts/incremental/benchmarking/result_efficiency/process0/sqlite/shell.c -v --disable incremental.load --enable incremental.save
This is at sqlite
commit cf9d36d1b3a84fb68d2e13acb790c449bff51c15
.
By tracing a smaller example extracted from sv-benchmarks/c/ldv-consumption/32_7a_cilled_linux-3.8-rc1-32_7a-drivers--net--ethernet--sfc--sfc.ko-ldv_main2_sequence_infinite_withcheck_stateful.cil.out.i
, it seems that this issue is caused by this todo about handling casts between different sizes.
Actually the TODO sounds like it's just about casts between different array sizes (e.g. int[2]
and int[4]
), but the incompatibility here is even worse: the array contents aren't being cast at all! In the benchmark, there's a cast (as part of union field access) from unsigned long long[1]
to unsigned int[2]
. And the IntDomain
values in the array are never cast to the correct type.
I don't think we should change the representation of the array here (there may be other pointers to the same array). Rather, when we read we need to check that the type we're using to read matches the one we expect the elements to have (c.f. https://github.com/goblint/analyzer/issues/582)
Other pointers to the array are irrelevant at this point: nothing is being changed here, this logic already is part of reading in eval_offset
. This is when you are reading from u32
when u64
was written (and the local state still does contain that):
union u {
unsigned long long u64[1];
unsigned int u32[2];
}
The following tests fail:
with the following exception (the same for both):
Fatal error: exception IntDomain.IncompatibleIKinds("ikinds unsigned long long and unsigned int are incompatible. Values: (Unknown int([0,64]),[0,18446744073709551615]) and (Unknown int([0,32]),[0,4294967295])")
My settings:
This issue seems to only occur when Apron is activated