Skip to content

Initialization of a flexible array member leads to cbmc crash or verification failure. #4206

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

Closed
andreast271 opened this issue Feb 16, 2019 · 9 comments

Comments

@andreast271
Copy link
Contributor

CBMC version: cbmc-5.11, cbmc-5.11-1479-ga86978840
Operating system: Linux 4.15.0-45-generic x86_64 GNU/Linux
Exact command line resulting in the issue: cbmc ccb.c , cbmc ccb.c --smt2
What behaviour did you expect: all 4 assertions should pass
What happened instead: 2 assertions fail (SAT backend), CBMC crash (smt2 backend)

In the following code all assertions should be true:

#include <assert.h>
struct St {
  char c;
  int d[];
};
struct St s = {'a', {11, 5}};

int main () {
  unsigned char c;
  c = c && 1;
  assert(c==0 || c==1);
  assert(s.d[1]==5);
  s.d[1] += c;
  assert(s.d[1]<8);
  assert(s.d[0]==11);
}

With cbmc, the behavior depends on the solver backend. With the default SAT solver backend, assertions 3 and 4 are failing for both cbmc-5.11 and cbmc-5.11-1479-ga86978840:

** Results:
ccb.c function main
[main.assertion.1] line 11 assertion c==0 || c==1: SUCCESS
[main.assertion.2] line 12 assertion s.d[1]==5: SUCCESS
[main.assertion.3] line 14 assertion s.d[1]<8: FAILURE
[main.assertion.4] line 15 assertion s.d[0]==11: FAILURE

With the smt2 backend, cbmc crashes. With cbmc-5.11 the error message is:

converting SSA
cannot unpack struct with non-byte aligned components

With cbmc-5.11-1479-ga86978840 from the develop branch (rev a869788), the error message is:

converting SSA
map::at
@tautschnig
Copy link
Collaborator

Just adding that with --no-simplify the assertion s.d[1]==5 also fails. We need to make sure we work with the actual size in the back-end, not the one we infer from the type.

@Smattr
Copy link

Smattr commented Jan 10, 2020

Is there a work around for this? I hit something that looks like the latter failure (converting SSA map::at) when using the SMT2 back end on cbmc-5.12-d8598f8-1368-g5e956891d. My example does not use flexible array members and I have not attempted to minimise it, but can do so if you think it's a different issue.

@jackhumphries
Copy link

@Smattr Did you discover a workaround?

@Smattr
Copy link

Smattr commented Nov 1, 2020

No, I don't think so. IIRC at the time I was trying to do something involving a suite of verification tools, so I simply lent more heavily on one of the others to get the job done instead of CBMC.

@martin-cs
Copy link
Collaborator

Work arounds at the bottom of this comment:

#5297 (comment)

@tautschnig
Copy link
Collaborator

We probably have more than one bug around flexible array members. Likely we should consider introducing a dedicated type (or at least some annotation to the containing struct) to handle these.

@SaswatPadhi
Copy link
Contributor

SaswatPadhi commented Mar 20, 2021

I think the crash with SMT backend might be fixed by #5904 (the PR is waiting for Z3 integration in CI).

@TGWDB
Copy link
Contributor

TGWDB commented Apr 6, 2021

Can confirm there is no crash with --smt2 and Z3.

tautschnig added a commit to tautschnig/cbmc that referenced this issue Feb 14, 2022
This addresses an existing todo in the code base: we need to come up
with a new type based on the actual initializer.

Fixes: diffblue#3653, diffblue#4206

Co-authored-by: Chengyu Zhang <[email protected]>
Co-authored-by: Andreas Tiemeyer <[email protected]>
tautschnig added a commit to tautschnig/cbmc that referenced this issue Feb 26, 2022
This addresses an existing todo in the code base: we need to come up
with a new type based on the actual initializer.

Fixes: diffblue#3653, diffblue#4206

Co-authored-by: Chengyu Zhang <[email protected]>
Co-authored-by: Andreas Tiemeyer <[email protected]>
tautschnig added a commit to tautschnig/cbmc that referenced this issue Feb 26, 2022
This addresses an existing todo in the code base: we need to come up
with a new type based on the actual initializer.

Fixes: diffblue#3653, diffblue#4206

Co-authored-by: Chengyu Zhang <[email protected]>
Co-authored-by: Andreas Tiemeyer <[email protected]>
@tautschnig
Copy link
Collaborator

Was fixed in #6661.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants