Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spurious overflow warnings due to partitioned arrays in globals #1565

Open
sim642 opened this issue Sep 6, 2024 · 0 comments
Open

Spurious overflow warnings due to partitioned arrays in globals #1565

sim642 opened this issue Sep 6, 2024 · 0 comments
Labels
bug precision sv-comp SV-COMP (analyses, results), witnesses

Comments

@sim642
Copy link
Member

sim642 commented Sep 6, 2024

In the sv-benchmarks run of #1552 with vojdani privatization I noticed a particularly odd spurious overflow warning:

[Warning][Integer > Overflow][CWE-190] Signed integer overflow (/mnt/goblint-svcomp/benchexec/sv-benchmarks/c/pthread-ext/25_stack-pthread.i:742:3-742:16)

The line in question is

  r = push(arg);

where both r and arg are int and so are the types for push.

Tracing revealed that these overflow warnings are emitted during smart_join of the partitioned array domain when it evaluates expressions. The weird location is because this isn't happening during a transfer function, but it's a join on an global unknown.

Although the problem only revealed itself with the vojdani privatization from #1552, the underlying problem is more general. It seems that partitioned arrays are side-effected to globals while still referring to local variables:

%%% priv: sideg memory (partitioned array:Array: Array (part. by newTop + 1): (Uninitialized -- 0 -- 0), IntDomLifter(intdomtuple):65)

A subsequent join in the solver then leads to the array domain trying to evaluate newTop + 1, where newTop cannot have any value (so it's VD.bot, then turned into VD.top). The overflow warning comes from trying to add to the supertop.

We probably should suppress overflow warnings from these partitioned array expression evaluations, but that's just a coverup: such expressions shouldn't be side-effected in the first place.

@sim642 sim642 added bug sv-comp SV-COMP (analyses, results), witnesses precision labels Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug precision sv-comp SV-COMP (analyses, results), witnesses
Projects
None yet
Development

No branches or pull requests

1 participant