pghs975uc
/
infer_clone
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'de4ad53ebc'
${ noResults }
infer_clone/infer/tests/codetoanalyze/c/pulse/issues.exp

43 lines
10 KiB
Raw Normal View History Unescape

[pulse] better traces when invalidation happens along the access trace Summary: As explained in the previous diff: when the access trace goes through the invalidation step there is no need to print the invalidation trace at all. Note: only a few sources of invalidation are handled at the moment. The following diffs gradually fix the other sources of invalidation. Reviewed By: skcho Differential Revision: D28098335 fbshipit-source-id: 5a5e6481e
4 years ago
codetoanalyze/c/pulse/frontend.c, assign_implicit_cast_bad, 8, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/frontend.c, assign_paren_bad, 8, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/interprocedural.c, call_if_freed_invalid2_bad, 0, NULLPTR_DEREFERENCE, no_bucket, ERROR, [calling context starts here,in call to `call_if_freed_invalid_latent`,is the null pointer,when calling `if_freed_invalid_latent` here,parameter `y` of if_freed_invalid_latent,invalid access occurs here]
codetoanalyze/c/pulse/interprocedural.c, call_if_freed_invalid_latent, 2, NULLPTR_DEREFERENCE, no_bucket, ERROR, [*** LATENT ***,is the null pointer,when calling `if_freed_invalid_latent` here,parameter `y` of if_freed_invalid_latent,invalid access occurs here]
ISL tests Reviewed By: jvillard Differential Revision: D24433559 fbshipit-source-id: 4d7a4c221
4 years ago
codetoanalyze/c/pulse/interprocedural.c, if_freed_invalid_latent, 3, USE_AFTER_FREE, no_bucket, ERROR, [*** LATENT ***,invalidation part of the trace starts here,parameter `y` of if_freed_invalid_latent,was invalidated by call to `free()`,use-after-lifetime part of the trace starts here,parameter `y` of if_freed_invalid_latent,invalid access occurs here]
[pulse] better traces when invalidation happens along the access trace Summary: As explained in the previous diff: when the access trace goes through the invalidation step there is no need to print the invalidation trace at all. Note: only a few sources of invalidation are handled at the moment. The following diffs gradually fix the other sources of invalidation. Reviewed By: skcho Differential Revision: D28098335 fbshipit-source-id: 5a5e6481e
4 years ago
codetoanalyze/c/pulse/interprocedural.c, test_modified_value_then_error_bad, 4, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
[pulse] report latent issues in "main" Summary: In main() all latent issues are manifest issues as the only parameters are user-controlled. Reviewed By: skcho Differential Revision: D28121535 fbshipit-source-id: eab54d5bc
4 years ago
codetoanalyze/c/pulse/latent.c, FN_nonlatent_use_after_free_bad, 6, USE_AFTER_FREE, no_bucket, ERROR, [*** LATENT ***,invalidation part of the trace starts here,parameter `x` of FN_nonlatent_use_after_free_bad,was invalidated by call to `free()`,use-after-lifetime part of the trace starts here,parameter `x` of FN_nonlatent_use_after_free_bad,invalid access occurs here]
codetoanalyze/c/pulse/latent.c, latent_use_after_free, 4, NULLPTR_DEREFERENCE, no_bucket, ERROR, [*** LATENT ***,source of the null value part of the trace starts here,is the null pointer,null pointer dereference part of the trace starts here,parameter `x` of latent_use_after_free,invalid access occurs here]
codetoanalyze/c/pulse/latent.c, latent_use_after_free, 4, USE_AFTER_FREE, no_bucket, ERROR, [*** LATENT ***,invalidation part of the trace starts here,parameter `x` of latent_use_after_free,was invalidated by call to `free()`,use-after-lifetime part of the trace starts here,parameter `x` of latent_use_after_free,invalid access occurs here]
codetoanalyze/c/pulse/latent.c, main, 3, USE_AFTER_FREE, no_bucket, ERROR, [calling context starts here,in call to `latent_use_after_free`,invalidation part of the trace starts here,parameter `x` of latent_use_after_free,was invalidated by call to `free()`,use-after-lifetime part of the trace starts here,parameter `x` of latent_use_after_free,invalid access occurs here]
codetoanalyze/c/pulse/latent.c, manifest_use_after_free, 0, USE_AFTER_FREE, no_bucket, ERROR, [calling context starts here,in call to `latent_use_after_free`,invalidation part of the trace starts here,parameter `x` of latent_use_after_free,was invalidated by call to `free()`,use-after-lifetime part of the trace starts here,parameter `x` of latent_use_after_free,invalid access occurs here]
[pulse] no longer drop attributes of dead addresses Summary: When garbage-collecting addresses we would also remove their attributes. But even though the addresses are no longer allocated in the heap, they might show up in the formula and so we need to remember facts about them. This forces us to detect leaks closer to the point where addresses are deleted from the heap, in AbductiveDomain.ml. This is a nice refactoring in itself: doing so fixes some other FNs where we sometimes missed leak detection on dead addresses. This also makes it unecessary to simplify InstanceOf eagerly when variables get out of scope. Some new {folly,std}::optionals false positives that either are similar to existing ones or involve unmodelled smart pointers. Reviewed By: da319 Differential Revision: D28126103 fbshipit-source-id: e3a903282
4 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_formal_leak_bad, 0, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by call to `malloc` (modelled),allocation part of the trace ends here,memory becomes unreachable here]
[pulse] Enable pulse memory leaks and disable biabduction one Summary: The new memory leaks analysis is now ready to be enabled by default and turned on in production. This also replaces the biabduction one which is now disabled. Reviewed By: jvillard Differential Revision: D21998666 fbshipit-source-id: 9cd95e894
5 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_interproc_no_free_bad, 0, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,when calling `create_p` here,allocated by call to `malloc` (modelled),allocation part of the trace ends here,memory becomes unreachable here]
[pulse] no longer drop attributes of dead addresses Summary: When garbage-collecting addresses we would also remove their attributes. But even though the addresses are no longer allocated in the heap, they might show up in the formula and so we need to remember facts about them. This forces us to detect leaks closer to the point where addresses are deleted from the heap, in AbductiveDomain.ml. This is a nice refactoring in itself: doing so fixes some other FNs where we sometimes missed leak detection on dead addresses. This also makes it unecessary to simplify InstanceOf eagerly when variables get out of scope. Some new {folly,std}::optionals false positives that either are similar to existing ones or involve unmodelled smart pointers. Reviewed By: da319 Differential Revision: D28126103 fbshipit-source-id: e3a903282
4 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_interproc_no_free_bad2, 5, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by call to `malloc` (modelled),allocation part of the trace ends here,memory becomes unreachable here]
[pulse] Enable pulse memory leaks and disable biabduction one Summary: The new memory leaks analysis is now ready to be enabled by default and turned on in production. This also replaces the biabduction one which is now disabled. Reviewed By: jvillard Differential Revision: D21998666 fbshipit-source-id: 9cd95e894
5 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_no_free_bad, 0, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by call to `malloc` (modelled),allocation part of the trace ends here,memory becomes unreachable here]
[pulse] resolve function pointers when known Summary: There's already all the ingredients to treat function pointers pretty well, even when stored inside (const) globals. In OpenSSL they use something like the added tests but the globals are not const... This may need tweaking via an option, eg to inline all global initializers, or filtered by global names/file names. Or just use the existing --pulse-model-{alloc,release}-pattern options. Reviewed By: skcho Differential Revision: D28221651 fbshipit-source-id: 5399f1141
4 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_ptr_leak_bad, 0, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,when calling `malloc_via_ptr` here,allocated by call to `malloc` (modelled),allocation part of the trace ends here,memory becomes unreachable here]
codetoanalyze/c/pulse/memory_leak.c, malloc_ptr_no_check_leak_bad, 2, NULLPTR_DEREFERENCE, no_bucket, ERROR, [source of the null value part of the trace starts here,when calling `malloc_via_ptr` here,assigned,is the null pointer,null pointer dereference part of the trace starts here,passed as argument to `malloc_via_ptr`,return from call to `malloc_via_ptr`,assigned,invalid access occurs here]
codetoanalyze/c/pulse/memory_leak.c, malloc_ptr_no_check_leak_bad, 3, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,when calling `malloc_via_ptr` here,allocated by call to `malloc` (modelled),allocation part of the trace ends here,memory becomes unreachable here]
[pulse] better traces when invalidation happens along the access trace Summary: As explained in the previous diff: when the access trace goes through the invalidation step there is no need to print the invalidation trace at all. Note: only a few sources of invalidation are handled at the moment. The following diffs gradually fix the other sources of invalidation. Reviewed By: skcho Differential Revision: D28098335 fbshipit-source-id: 5a5e6481e
4 years ago
codetoanalyze/c/pulse/nullptr.c, bug_after_abduction_bad, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/nullptr.c, bug_after_malloc_result_test_bad, 4, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/nullptr.c, bug_with_allocation_bad, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
[pulse] no longer drop attributes of dead addresses Summary: When garbage-collecting addresses we would also remove their attributes. But even though the addresses are no longer allocated in the heap, they might show up in the formula and so we need to remember facts about them. This forces us to detect leaks closer to the point where addresses are deleted from the heap, in AbductiveDomain.ml. This is a nice refactoring in itself: doing so fixes some other FNs where we sometimes missed leak detection on dead addresses. This also makes it unecessary to simplify InstanceOf eagerly when variables get out of scope. Some new {folly,std}::optionals false positives that either are similar to existing ones or involve unmodelled smart pointers. Reviewed By: da319 Differential Revision: D28126103 fbshipit-source-id: e3a903282
4 years ago
codetoanalyze/c/pulse/nullptr.c, create_null_path2_latent, 8, NULLPTR_DEREFERENCE, no_bucket, ERROR, [*** LATENT ***,source of the null value part of the trace starts here,assigned,is the null pointer,null pointer dereference part of the trace starts here,parameter `p` of create_null_path2_latent,invalid access occurs here]
[pulse] record all the invalidations we can in histories Summary: Building on the infra in the previous commits, "fix" all the call sites that introduce invalidations to make sure they also update the corresponding histories. This is only possible to do when the access leading to the invalidation can be recorded. Right now the only place that's untraceable is the model of `free`/`delete`, because it happens to be the only place where we invalidate an address without knowing where it comes from (`free(v)`: what was v's access path? we could track this in the future). Reviewed By: skcho Differential Revision: D28118764 fbshipit-source-id: de67f449e
4 years ago
codetoanalyze/c/pulse/nullptr.c, malloc_no_check_bad, 2, NULLPTR_DEREFERENCE, no_bucket, ERROR, [allocated by call to `malloc` (modelled),is the null pointer,assigned,invalid access occurs here]
[pulse] use term_eqs Summary: Whenever an equality "t = v" (t an arbitrary term, v a variable) is added (or "v = t"), remember the "t -> v" mapping after canonicalising t and v. Use this to detect when two variables are equal to the same term: `t = v` and `t = v'` now yields `v = v'` to be added to the equality relation of variables. This increases the precision of the arithmetic engine. Interestingly, the impact on most code I've tried is: 1. mostly same perfs as before, if a bit slower (could be within noise) 2. slightly more (latent) bugs reported in absolute numbers I would have expected it to be more expensive and yield fewer bugs (as fewer false positives), but there could be second-order effects at play here where we get more coverage. We definitely get more latent issues due to dereferencing pointers after testing nullness, as can be seen in the unit tests as well, which may alone explain (2). There's some complexity when adding term equalities where the term is linear, as we also need to add it to `linear_eqs` but `term_eqs` and `linear_eqs` are interested in slightly different normal forms. Reviewed By: skcho Differential Revision: D27331336 fbshipit-source-id: 7314e127a
4 years ago
codetoanalyze/c/pulse/nullptr.c, malloc_then_call_create_null_path_then_deref_unconditionally_latent, 7, NULLPTR_DEREFERENCE, no_bucket, ERROR, [*** LATENT ***,source of the null value part of the trace starts here,allocated by call to `malloc` (modelled),is the null pointer,null pointer dereference part of the trace starts here,parameter `p` of malloc_then_call_create_null_path_then_deref_unconditionally_latent,invalid access occurs here]
[pulse] no longer drop attributes of dead addresses Summary: When garbage-collecting addresses we would also remove their attributes. But even though the addresses are no longer allocated in the heap, they might show up in the formula and so we need to remember facts about them. This forces us to detect leaks closer to the point where addresses are deleted from the heap, in AbductiveDomain.ml. This is a nice refactoring in itself: doing so fixes some other FNs where we sometimes missed leak detection on dead addresses. This also makes it unecessary to simplify InstanceOf eagerly when variables get out of scope. Some new {folly,std}::optionals false positives that either are similar to existing ones or involve unmodelled smart pointers. Reviewed By: da319 Differential Revision: D28126103 fbshipit-source-id: e3a903282
4 years ago
codetoanalyze/c/pulse/nullptr.c, null_alias_bad, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [allocated by call to `malloc` (modelled),is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/nullptr.c, null_alias_bad, 4, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by call to `malloc` (modelled),allocation part of the trace ends here,memory becomes unreachable here]
[pulse] better traces when invalidation happens along the access trace Summary: As explained in the previous diff: when the access trace goes through the invalidation step there is no need to print the invalidation trace at all. Note: only a few sources of invalidation are handled at the moment. The following diffs gradually fix the other sources of invalidation. Reviewed By: skcho Differential Revision: D28098335 fbshipit-source-id: 5a5e6481e
4 years ago
codetoanalyze/c/pulse/nullptr.c, nullptr_deref_young_bad, 5, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/traces.c, access_null_deref_bad, 2, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
[pulse] record invalidation events in histories Summary: The eventual goal is to stop having separate sections of the trace ("invalidation part" + "access part") when the "access part" already goes through the invalidation step. For this, it needs to record when a value is made invalid along the path. This is also important for assignements to NULL/0/nullptr/nil: right now the way we record that 0 is not a valid address is via an attribute attached to the abstract value that corresponds to 0. This makes traces inconsistent sometimes: 0 can appear in many places in the same function and we won't necessarily pick the correct one. In other words, attaching traces to *values* is fragile, as the same value can be produced in many ways. On the other hand, histories are stored at the point of access, eg x->f, so have a much better chance of being correct. See added test: right now its traces is completely wrong and makes the 0 in `if (utf16StringLen == 0)` the source of the NULL value instead of the return of `malloc()`! This diff makes the traces slightly more verbose for now but this is fixed in a following diff as the traces that got longer are those that don't actually need an "invalidation" trace. Reviewed By: skcho Differential Revision: D28098337 fbshipit-source-id: e17929259
4 years ago
codetoanalyze/c/pulse/traces.c, access_use_after_free_bad, 2, USE_AFTER_FREE, no_bucket, ERROR, [invalidation part of the trace starts here,parameter `l` of access_use_after_free_bad,was invalidated by call to `free()`,use-after-lifetime part of the trace starts here,parameter `l` of access_use_after_free_bad,invalid access occurs here]
[pulse] record all the invalidations we can in histories Summary: Building on the infra in the previous commits, "fix" all the call sites that introduce invalidations to make sure they also update the corresponding histories. This is only possible to do when the access leading to the invalidation can be recorded. Right now the only place that's untraceable is the model of `free`/`delete`, because it happens to be the only place where we invalidate an address without knowing where it comes from (`free(v)`: what was v's access path? we could track this in the future). Reviewed By: skcho Differential Revision: D28118764 fbshipit-source-id: de67f449e
4 years ago
codetoanalyze/c/pulse/traces.c, call_makes_null_deref_manifest_bad, 4, NULLPTR_DEREFERENCE, no_bucket, ERROR, [calling context starts here,in call to `something_about_strings_latent`,allocated by call to `malloc` (modelled),is the null pointer,assigned,invalid access occurs here]
[pulse] better traces when invalidation happens along the access trace Summary: As explained in the previous diff: when the access trace goes through the invalidation step there is no need to print the invalidation trace at all. Note: only a few sources of invalidation are handled at the moment. The following diffs gradually fix the other sources of invalidation. Reviewed By: skcho Differential Revision: D28098335 fbshipit-source-id: 5a5e6481e
4 years ago
codetoanalyze/c/pulse/traces.c, simple_deref, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/traces.c, simple_deref_via_alias, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,assigned,invalid access occurs here]
[pulse] record all the invalidations we can in histories Summary: Building on the infra in the previous commits, "fix" all the call sites that introduce invalidations to make sure they also update the corresponding histories. This is only possible to do when the access leading to the invalidation can be recorded. Right now the only place that's untraceable is the model of `free`/`delete`, because it happens to be the only place where we invalidate an address without knowing where it comes from (`free(v)`: what was v's access path? we could track this in the future). Reviewed By: skcho Differential Revision: D28118764 fbshipit-source-id: de67f449e
4 years ago
codetoanalyze/c/pulse/traces.c, something_about_strings_latent, 12, NULLPTR_DEREFERENCE, no_bucket, ERROR, [*** LATENT ***,allocated by call to `malloc` (modelled),is the null pointer,assigned,invalid access occurs here]
[pulse] Revise trace of uninitialized value check Summary: This diff revises the trace generation of the uninitialized value checker, by introducing a new diagnostics for it. Reviewed By: jvillard Differential Revision: D25433775 fbshipit-source-id: 1279c0de4
4 years ago
codetoanalyze/c/pulse/uninit.c, call_to_use_and_mayinit_bad, 2, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [variable `x` declared here,read to uninitialized value occurs here]
codetoanalyze/c/pulse/uninit.c, dereference_bad, 2, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [variable `p` declared here,read to uninitialized value occurs here]
codetoanalyze/c/pulse/uninit.c, interprocedural_nop_in_callee_bad, 3, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [variable `x` declared here,read to uninitialized value occurs here]
codetoanalyze/c/pulse/uninit.c, interprocedural_read_in_callee_bad, 2, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [variable `x` declared here,when calling `read_int_ref` here,parameter `p` of read_int_ref,read to uninitialized value occurs here]
[pulse] Uninitialized check for struct fields Reviewed By: jvillard Differential Revision: D25371929 fbshipit-source-id: 966f333e3
4 years ago
codetoanalyze/c/pulse/uninit.c, interprocedural_struct_bad, 3, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [struct field address `f2` created,read to uninitialized value occurs here]
[pulse] Revise trace of uninitialized value check Summary: This diff revises the trace generation of the uninitialized value checker, by introducing a new diagnostics for it. Reviewed By: jvillard Differential Revision: D25433775 fbshipit-source-id: 1279c0de4
4 years ago
codetoanalyze/c/pulse/uninit.c, interprocedural_uninit_in_callee_bad, 3, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [passed as argument to `uninit`,return from call to `uninit`,assigned,read to uninitialized value occurs here]
codetoanalyze/c/pulse/uninit.c, malloc_bad, 3, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [allocated by call to `malloc` (modelled),assigned,read to uninitialized value occurs here]
[uninit] Revise error message to include access paths Summary: This diff finds a declared variable name or declared field names from trace, then constructs an error message including access paths. Reviewed By: jvillard Differential Revision: D26544275 fbshipit-source-id: 135c90a1b
4 years ago
codetoanalyze/c/pulse/uninit.c, nested_struct_bad, 3, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [struct field address `g1.f1` created,when calling `read_g1_f1` here,parameter `x` of read_g1_f1,read to uninitialized value occurs here]
[pulse] Revise trace of uninitialized value check Summary: This diff revises the trace generation of the uninitialized value checker, by introducing a new diagnostics for it. Reviewed By: jvillard Differential Revision: D25433775 fbshipit-source-id: 1279c0de4
4 years ago
codetoanalyze/c/pulse/uninit.c, self_assign_bad, 2, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [variable `x` declared here,read to uninitialized value occurs here]