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 '4e18aa100d'
${ noResults }
infer_clone/infer/tests/codetoanalyze/c/pulse/issues.exp

59 lines
14 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]
[pulse] correct order of calling context in trace Summary: The order was reversed when printing the trace, leading to confusion. Also make sure we indicate which part of the trace we are printing when there is more than one part (either context + access or invalidation + access, or all three). Also start nesting at <calling context length> to better represent the role of the calling context visually. Reviewed By: da319 Differential Revision: D28329263 fbshipit-source-id: b691fb1f4
4 years ago
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`,null pointer dereference part of the trace starts here,is the null pointer,when calling `if_freed_invalid_latent` 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, 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]
[pulse] follow values inside function calls Summary: Turns out the mistake was pretty simple: we just forgot to keep the history of the return value in the callee and add it to the caller's. Reviewed By: skcho Differential Revision: D28385941 fbshipit-source-id: 40fe09c99
4 years ago
codetoanalyze/c/pulse/interprocedural.c, follow_value_by_ref_bad, 5, NULLPTR_DEREFERENCE, no_bucket, ERROR, [in call to `return_null`,is the null pointer,assigned,assigned,return from call to `return_null`,in call to `return_first`,parameter `x` of return_first,assigned,assigned,return from call to `return_first`,invalid access occurs here]
codetoanalyze/c/pulse/interprocedural.c, follow_value_by_ret_bad, 4, NULLPTR_DEREFERENCE, no_bucket, ERROR, [in call to `return_null`,is the null pointer,assigned,returned,return from call to `return_null`,assigned,in call to `return_first`,parameter `x` of return_first,assigned,returned,return from call to `return_first`,assigned,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] correct order of calling context in trace Summary: The order was reversed when printing the trace, leading to confusion. Also make sure we indicate which part of the trace we are printing when there is more than one part (either context + access or invalidation + access, or all three). Also start nesting at <calling context length> to better represent the role of the calling context visually. Reviewed By: da319 Differential Revision: D28329263 fbshipit-source-id: b691fb1f4
4 years ago
codetoanalyze/c/pulse/interprocedural.c, latent, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [*** LATENT ***,is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/interprocedural.c, make_latent_manifest, 0, NULLPTR_DEREFERENCE, no_bucket, ERROR, [calling context starts here,in call to `propagate_latent_3_latent`,in call to `propagate_latent_2_latent`,in call to `propagate_latent_1_latent`,in call to `latent`,null pointer dereference part of the trace starts here,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/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 leaks as soon as values become unreachable Summary: This makes reports more readable: they were all at the end of functions, currently. This is actually quite tricky to do as it involves detecting which locations are unreachable. Some of this logic can/should probably be shared with `AbductiveDomain.discard_unreachable` but at the moment that's not the case. Reviewed By: skcho Differential Revision: D28382590 fbshipit-source-id: bd4239a0c
4 years ago
codetoanalyze/c/pulse/interprocedural.c, trace_correctly_through_wrappers_bad, 4, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,when calling `malloc_wrapper_2` here,when calling `malloc_wrapper_1` here,allocated by `malloc` here,memory becomes unreachable 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] add "fat pointers" mem leak tests Summary: yay tests! Reviewed By: skcho Differential Revision: D28606677 fbshipit-source-id: ce930e660
4 years ago
codetoanalyze/c/pulse/memory_leak.c, alloc_ref_counted_bad, 6, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by `malloc` here,memory becomes unreachable here]
[pulse] deduplicate histories and traces for memleaks Summary: Most/all of the time we expect the history of the value to faithfully trace how it got allocated. That history was then added as a prefix of the trace leading to the same place, leading to duplicate information in the report trace. We may need to do the same for other bug types. Reviewed By: ezgicicek Differential Revision: D28536891 fbshipit-source-id: a83a2d038
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 `malloc` here,memory becomes unreachable here]
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 `malloc` here,memory becomes unreachable here]
[pulse] report leaks as soon as values become unreachable Summary: This makes reports more readable: they were all at the end of functions, currently. This is actually quite tricky to do as it involves detecting which locations are unreachable. Some of this logic can/should probably be shared with `AbductiveDomain.discard_unreachable` but at the moment that's not the case. Reviewed By: skcho Differential Revision: D28382590 fbshipit-source-id: bd4239a0c
4 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_interproc_no_free_bad2, 4, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by `malloc` here,memory becomes unreachable here]
[pulse] deduplicate histories and traces for memleaks Summary: Most/all of the time we expect the history of the value to faithfully trace how it got allocated. That history was then added as a prefix of the trace leading to the same place, leading to duplicate information in the report trace. We may need to do the same for other bug types. Reviewed By: ezgicicek Differential Revision: D28536891 fbshipit-source-id: a83a2d038
4 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 `malloc` here,memory becomes unreachable here]
[pulse] report leaks as soon as values become unreachable Summary: This makes reports more readable: they were all at the end of functions, currently. This is actually quite tricky to do as it involves detecting which locations are unreachable. Some of this logic can/should probably be shared with `AbductiveDomain.discard_unreachable` but at the moment that's not the case. Reviewed By: skcho Differential Revision: D28382590 fbshipit-source-id: bd4239a0c
4 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_out_parameter_local_mutation_bad, 3, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by `malloc` here,memory becomes unreachable here]
[pulse] deduplicate histories and traces for memleaks Summary: Most/all of the time we expect the history of the value to faithfully trace how it got allocated. That history was then added as a prefix of the trace leading to the same place, leading to duplicate information in the report trace. We may need to do the same for other bug types. Reviewed By: ezgicicek Differential Revision: D28536891 fbshipit-source-id: a83a2d038
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 `malloc` here,memory becomes unreachable here]
[pulse] report leaks as soon as values become unreachable Summary: This makes reports more readable: they were all at the end of functions, currently. This is actually quite tricky to do as it involves detecting which locations are unreachable. Some of this logic can/should probably be shared with `AbductiveDomain.discard_unreachable` but at the moment that's not the case. Reviewed By: skcho Differential Revision: D28382590 fbshipit-source-id: bd4239a0c
4 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_ptr_no_check_leak_bad, 2, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,when calling `malloc_via_ptr` here,allocated by `malloc` here,memory becomes unreachable here]
[pulse] follow values inside function calls Summary: Turns out the mistake was pretty simple: we just forgot to keep the history of the return value in the callee and add it to the caller's. Reviewed By: skcho Differential Revision: D28385941 fbshipit-source-id: 40fe09c99
4 years ago
codetoanalyze/c/pulse/memory_leak.c, malloc_ptr_no_check_leak_bad, 2, NULLPTR_DEREFERENCE, no_bucket, ERROR, [in call to `malloc_via_ptr`,is the null pointer,returned,return from call to `malloc_via_ptr`,assigned,invalid access occurs here]
[pulse] model realloc(3) Summary: Let's model all the dynamic memory management functions as they all work together and are important for a lot of C projects. Reviewed By: ezgicicek Differential Revision: D28543008 fbshipit-source-id: f130e1ab6
4 years ago
codetoanalyze/c/pulse/memory_leak.c, realloc_no_check_bad, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [in call to `malloc` (modelled),is the null pointer,assigned,in call to `realloc_wrapper`,in call to `realloc` (modelled),is the null pointer,returned,return from call to `realloc_wrapper`,assigned,invalid access occurs here]
codetoanalyze/c/pulse/memory_leak.c, realloc_no_free_bad, 2, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,when calling `realloc_wrapper` here,allocated by `realloc` here,memory becomes unreachable here]
[pulse] report leaks as soon as values become unreachable Summary: This makes reports more readable: they were all at the end of functions, currently. This is actually quite tricky to do as it involves detecting which locations are unreachable. Some of this logic can/should probably be shared with `AbductiveDomain.discard_unreachable` but at the moment that's not the case. Reviewed By: skcho Differential Revision: D28382590 fbshipit-source-id: bd4239a0c
4 years ago
codetoanalyze/c/pulse/memory_leak.c, report_leak_in_correct_line_bad, 2, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by `malloc` here,memory becomes unreachable here]
[pulse] suppress leaks that are not leaks due to pointer arithmetic Summary: This seems to be a popular source of false positives. Reviewed By: skcho Differential Revision: D28576767 fbshipit-source-id: d8d4d60d6
4 years ago
codetoanalyze/c/pulse/memory_leak.c, return_malloc_deref_bad, 4, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by `malloc` here,memory becomes unreachable here]
[pulse] more config options to model dynamic memory management Summary: Add an option for realloc and fiddle with the other options' help for consistency. Moved the memory leak test to memory_leak.c and added more. Moved the place where we take the options into account closer to their corresponding models to defend a bit against modifying one without modifying the other. Reviewed By: da319 Differential Revision: D28543340 fbshipit-source-id: 75894d06d
4 years ago
codetoanalyze/c/pulse/memory_leak.c, test_config_options_no_free_bad, 2, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by `my_realloc` here,memory becomes unreachable here]
codetoanalyze/c/pulse/memory_leak.c, user_malloc_leak_bad, 0, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by `a_malloc` 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]
[pulse] delay leak reporting until summary is created Summary: This is needed for the next diff. It was a bit annoying to report leaks in two different places, now it's just in one. Reviewed By: skcho Differential Revision: D28576768 fbshipit-source-id: 4f23b43cb
4 years ago
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]
[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_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] a few textual changes in traces Summary: - Changed "passed as argument to f" to "in call to f", as these do not always correspond to passing an argument (eg could be a value returned from f) - Changed "assigned" to "returned" when appropriate - Changed the model of malloc() to not say "allocated" in the null case - Don't print "returned from f" when there was no event inside f: just print "in call to f". Reviewed By: da319 Differential Revision: D28413900 fbshipit-source-id: bc85625e3
4 years ago
codetoanalyze/c/pulse/nullptr.c, malloc_no_check_bad, 2, NULLPTR_DEREFERENCE, no_bucket, ERROR, [in call to `malloc` (modelled),is the null pointer,assigned,invalid access occurs here]
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,in 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] report leaks as soon as values become unreachable Summary: This makes reports more readable: they were all at the end of functions, currently. This is actually quite tricky to do as it involves detecting which locations are unreachable. Some of this logic can/should probably be shared with `AbductiveDomain.discard_unreachable` but at the moment that's not the case. Reviewed By: skcho Differential Revision: D28382590 fbshipit-source-id: bd4239a0c
4 years ago
codetoanalyze/c/pulse/nullptr.c, null_alias_bad, 3, MEMORY_LEAK, no_bucket, ERROR, [allocation part of the trace starts here,allocated by `malloc` here,memory becomes unreachable here]
[pulse] a few textual changes in traces Summary: - Changed "passed as argument to f" to "in call to f", as these do not always correspond to passing an argument (eg could be a value returned from f) - Changed "assigned" to "returned" when appropriate - Changed the model of malloc() to not say "allocated" in the null case - Don't print "returned from f" when there was no event inside f: just print "in call to f". Reviewed By: da319 Differential Revision: D28413900 fbshipit-source-id: bc85625e3
4 years ago
codetoanalyze/c/pulse/nullptr.c, null_alias_bad, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [in 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/nullptr.c, nullptr_deref_young_bad, 5, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,invalid access occurs here]
[pulse][4/5] add a path context to record timestamps Summary: Add a new `PathContext.t` component to the abstract state. For now it tracks only the current "timestamp" of symbolic execution inside the procedure, i.e. which step of symbolic execution we are in (bumped by 1 each time we've executed one instruction). In the future this will also hold, eg, which conditionals we've been through on the path (for reporting traces with that information). Most of the diff is about propagating the path context through many of the APIs. We use timestamps only in `MustBeValid` attributes to report the first incorrect access in a function call for now. Reviewed By: skcho Differential Revision: D28674726 fbshipit-source-id: 2cd825e73
4 years ago
codetoanalyze/c/pulse/nullptr.c, report_correct_error_among_multiple_bad, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [is the null pointer,assigned,when calling `several_dereferences_ok` here,parameter `z` of several_dereferences_ok,invalid access occurs here]
[pulse] functional unknown functions Summary: Unknown functions may create false positives as well as false negatives for Pulse. Let's consider that unknown functions behave "functionally", or at least that a functional behaviour is a possible behaviour for them: when called with the same parameter values, they should return the same value. This is implemented purely in the arithmetic domain by recording `v_return = f_unknown(v1, v2, ..., vN)` for each call to unknown functions `f_unknown` with values `v1`, `v2`, ..., `vN` (and return `v_return`). The hope is that this will create more false negatives than false positives, as several FPs have been observed on real code that would be suppressed with this heuristic. The other effect this has on reports is to record hypotheses made on the return values of unknown functions into the "pruned" part of formulas, which inhibits reporting on paths whose feasibility depends on the return value of unknown functions (by making these issues latent instead). This should allow us to control the amount of FPs until we model more functions. Reviewed By: skcho Differential Revision: D27798275 fbshipit-source-id: d31cfb8b6
4 years ago
codetoanalyze/c/pulse/nullptr.c, unknown_from_parameters_latent, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [*** LATENT ***,is the null pointer,assigned,invalid access occurs here]
codetoanalyze/c/pulse/nullptr.c, unknown_with_different_values_bad, 3, NULLPTR_DEREFERENCE, no_bucket, ERROR, [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, 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] a few textual changes in traces Summary: - Changed "passed as argument to f" to "in call to f", as these do not always correspond to passing an argument (eg could be a value returned from f) - Changed "assigned" to "returned" when appropriate - Changed the model of malloc() to not say "allocated" in the null case - Don't print "returned from f" when there was no event inside f: just print "in call to f". Reviewed By: da319 Differential Revision: D28413900 fbshipit-source-id: bc85625e3
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`,null pointer dereference part of the trace starts here,in 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] a few textual changes in traces Summary: - Changed "passed as argument to f" to "in call to f", as these do not always correspond to passing an argument (eg could be a value returned from f) - Changed "assigned" to "returned" when appropriate - Changed the model of malloc() to not say "allocated" in the null case - Don't print "returned from f" when there was no event inside f: just print "in call to f". Reviewed By: da319 Differential Revision: D28413900 fbshipit-source-id: bc85625e3
4 years ago
codetoanalyze/c/pulse/traces.c, something_about_strings_latent, 12, NULLPTR_DEREFERENCE, no_bucket, ERROR, [*** LATENT ***,in 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] follow values inside function calls Summary: Turns out the mistake was pretty simple: we just forgot to keep the history of the return value in the callee and add it to the caller's. Reviewed By: skcho Differential Revision: D28385941 fbshipit-source-id: 40fe09c99
4 years ago
codetoanalyze/c/pulse/uninit.c, interprocedural_uninit_in_callee_bad, 3, PULSE_UNINITIALIZED_VALUE, no_bucket, ERROR, [in call to `uninit`,allocated by call to `malloc` (modelled),returned,return from call to `uninit`,assigned,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, 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]