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 '74670cb0ba'
${ noResults }
infer_clone/infer/tests/codetoanalyze/cpp/racerd/issues.exp

19 lines
3.7 KiB
Raw Normal View History Unescape

[thread-safety][c++] Change to LOCK_CONSISTENCY_VIOLATION issue type Summary: Use a distinct issue type for the Java and C++ concurrency analyses, as the properties they are checking are significantly different. Reviewed By: sblackshear Differential Revision: D6151682 fbshipit-source-id: 00e00eb
7 years ago
codetoanalyze/cpp/racerd/basics.cpp, basics::Basic_get2, 3, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_written`,<Write trace>,access to `&this.suspiciously_written`]
codetoanalyze/cpp/racerd/basics.cpp, basics::Basic_get4, 0, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_read`,<Write trace>,access to `&this.suspiciously_read`]
codetoanalyze/cpp/racerd/basics.cpp, basics::Basic_get5, 0, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,call to basics::Basic_get_private_suspiciously_read,access to `&this.suspiciously_read`,<Write trace>,access to `&this.suspiciously_read`]
codetoanalyze/cpp/racerd/locals_ownership.cpp, locals::Ownership_test2_bad, 5, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&x.f`,<Write trace>,access to `&x.f`]
codetoanalyze/cpp/racerd/locals_ownership.cpp, locals::Ownership_test3_bad, 5, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&x.f`,<Write trace>,access to `&x.f`]
codetoanalyze/cpp/racerd/lock_guard.cpp, basics::LockGuard_get2, 3, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_written`,<Write trace>,access to `&this.suspiciously_written`]
codetoanalyze/cpp/racerd/lock_guard.cpp, basics::LockGuard_get4, 0, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_read`,<Write trace>,access to `&this.suspiciously_read`]
codetoanalyze/cpp/racerd/lock_guard.cpp, basics::LockGuard_test1, 2, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_read`,<Write trace>,access to `&this.suspiciously_read`]
codetoanalyze/cpp/racerd/lock_guard_with_scope.cpp, basics::LockGuardWithScope_get2, 3, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_written`,<Write trace>,access to `&this.suspiciously_written`]
codetoanalyze/cpp/racerd/lock_guard_with_scope.cpp, basics::LockGuardWithScope_get4, 0, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_read`,<Write trace>,access to `&this.suspiciously_read`]
[reporting] Report access path from the initial sink rather than the final sink. Summary: In a thread safety report we used the access path from the final sink. This diffs change the report to include the expanded access path from the initial sink. Reviewed By: sblackshear Differential Revision: D6297848 fbshipit-source-id: 2386063
7 years ago
codetoanalyze/cpp/racerd/reporting.cpp, reporting::Basic_call1, 1, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,call to reporting::Basic_test,access to `&xparam.x1.w`,<Write trace>,call to reporting::Basic_call1,call to reporting::Basic_test,access to `&xparam.x1.w`]
codetoanalyze/cpp/racerd/reporting.cpp, reporting::Basic_test_unlock, 0, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,call to reporting::Basic_call1,call to reporting::Basic_test,access to `&xparam.x1.w`,<Write trace>,call to reporting::Basic_call1,call to reporting::Basic_test,access to `&xparam.x1.w`]
[thread-safety][c++] Change to LOCK_CONSISTENCY_VIOLATION issue type Summary: Use a distinct issue type for the Java and C++ concurrency analyses, as the properties they are checking are significantly different. Reviewed By: sblackshear Differential Revision: D6151682 fbshipit-source-id: 00e00eb
7 years ago
codetoanalyze/cpp/racerd/unique_lock.cpp, basics::UniqueLock_get2, 3, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_written1`,<Write trace>,access to `&this.suspiciously_written1`]
codetoanalyze/cpp/racerd/unique_lock.cpp, basics::UniqueLock_get2, 4, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_written2`,<Write trace>,access to `&this.suspiciously_written2`]
codetoanalyze/cpp/racerd/unique_lock.cpp, basics::UniqueLock_get4, 1, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_read1`,<Write trace>,access to `&this.suspiciously_read1`]
codetoanalyze/cpp/racerd/unique_lock.cpp, basics::UniqueLock_get4, 2, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_read2`,<Write trace>,access to `&this.suspiciously_read2`]
[thread-safety][c++] Model std::unique_lock::owns_lock Summary: Code often uses std::unique_lock::owns_lock to test if a deferred lock using the 2-arg std::unique_lock constructor actually acquired the lock. Reviewed By: sblackshear Differential Revision: D6181631 fbshipit-source-id: 11e9df2
7 years ago
codetoanalyze/cpp/racerd/unique_lock.cpp, basics::UniqueLock_get5, 5, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_read1`,<Write trace>,access to `&this.suspiciously_read1`]
[LockConsistency] Model std::unique_lock::try_lock Summary: `std::unique_lock` constructor allows to create a unique lock without locking the mutex. `std::unique_lock::try_lock` returns true if mutex has been acquired successfully, and false otherwise. It could be that an exception is being thrown while trying to acquire mutex, which is not modeled. Reviewed By: jberdine Differential Revision: D6185568 fbshipit-source-id: 192bf10
7 years ago
codetoanalyze/cpp/racerd/unique_lock.cpp, basics::UniqueLock_get6, 5, LOCK_CONSISTENCY_VIOLATION, [<Read trace>,access to `&this.suspiciously_read1`,<Write trace>,access to `&this.suspiciously_read1`]