Undefined behavior in tasks due to division by zero

[lembergerth]

The ESBMC team (@mikhailramalho) was able to create the attached list of tasks that may contain a division by zero.

To my knowledge, the following four tasks are already confirmed to contain a division by zero: loop-industry-pattern/ofuf_1_true-unreach-call.c loop-industry-pattern/ofuf_2_true-unreach-call.c loop-industry-pattern/ofuf_3_true-unreach-call.c loop-industry-pattern/ofuf_4_true-unreach-call.c

The other tasks still have to be confirmed.

@dbeyer proposed to solve these issues by inserting before a line x/y a call avoid_zero(y) that is implemented by body {if (!y) {abort();}} .

Since there is only little time left to fix these tasks for SVCOMP'18, this Issue aims to coordinate the work on these tasks.

If you are willing to fix any of the tasks listed in the attached list (the proposed solution can also be used if division by zero is not confirmed), please comment on this issue with the list of tasks that you will try to fix. Taking a block of tasks instead of cherry picking would be the easiest to coordinate.

List of tasks that must be fixed: log.txt

[mutilin]

Does abort() lead to violating of the memcleanup property in some cases? or any other? Otherwise, the definition __VERIFIER_assume(expr) {if(!expr) abort();} looks fine to me.

[lembergerth]

Hi all, thanks @danieldietsch and @lucasccordeiro for fixing some of the tasks, especially for fixing the ones you asked me to do!

There are 82 tasks with a potential divison by zero left (division_by_zero_left.txt).

Was someone able to confirm or reject some of these tasks? @dbeyer , what will happen to the tasks if the division by zero can not be confirmed? Will they be removed from the benchmark set of SV-COMP'18, or will they stay?

[danieldietsch]

We fixed various things in our tool and I am just rerunning the remaining div-by-zeros -- should be finished soon.

[danieldietsch]

Ok, so we can add the following results:

proof for absence of divison by zero

• ldv-linux-3.4-simple/32_1_cilled_true-unreach-call_ok_nondet_linux-3.4-32_1-drivers--regulator--max1586.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c
• ldv-linux-3.4-simple/43_1a_cilled_true-unreach-call_ok_nondet_linux-43_1a-drivers--input--misc--rotary_encoder_false-termination.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c
• ldv-linux-3.4-simple/43_1a_cilled_true-unreach-call_ok_nondet_linux-43_1a-drivers--media--common--tuners--tda18218_false-termination.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c

confirmed divison by zero

• ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rc1-32_7a-drivers--media--usb--gspca--gspca_topro.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c
• ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rc1-32_7a-drivers--net--ethernet--cisco--enic--enic.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c
• ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rc1-32_7a-drivers--video--udlfb.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c
• ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rc1-drivers--video--udlfb.ko-main.cil.out.c
• ldv-linux-3.16-rc1/43_2a_consumption_linux-3.16-rc1.tar.xz-43_2a-drivers--net--ethernet--cisco--enic--enic.ko-entry_point_true-unreach-call.cil.out.c
• ldv-linux-3.4-simple/43_1a_cilled_true-unreach-call_ok_nondet_linux-43_1a-drivers--tty--serial--altera_uart.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c

I will go ahead and try to fix the 6 division by zero files.

[mchalupa]

I can confirm division by zero in ldv-linux-4.2-rc1/linux-4.2-rc1.tar.xz-32_7a-drivers--staging--lustre--lustre--libcfs--libcfs.ko-entry_point_true-unreach-call.cil.out.c on line 16701. As __bitmap_weight is not defined, assuming it can return anything, it can return 0 (line 6516). This 0 is then returned from cpumask_weight.

[dbeyer]

Can this issue be closed? @leostrakosch ?

[lembergerth]

There are still unconfirmed, potential divisions by zero left.

What should we do with these tasks? We could add a precautionary __VERIFIER_assume at every such location, or ignore them until it is confirmed that a divison by zero really is possible.

[dbeyer]

Yes, the latter, i.e., close the issue for now and if somebody finds a div-by-zero, then the new label is added to the verification task.

[danieldietsch]

Can we keep the issue open? Its easier to track the remaining candidates.