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 'c8489cb3ac'
${ noResults }
infer_clone/infer/tests/codetoanalyze/java/threadsafety/issues.exp

95 lines
20 KiB
Raw Normal View History Unescape

[thread-safety] model certain methods of Resources as @Functional Summary: Should stop us from reporting on benign races of fields that are caching resources. Reviewed By: peterogithub Differential Revision: D4538037 fbshipit-source-id: 15236b4
8 years ago
codetoanalyze/java/threadsafety/AndroidModels.java, void AndroidModels.someResourceMethodsNotFunctionalBad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.AndroidModels.mField]
[threadsafety] read/write races Summary: Reports on reads that have one or more conflicting writes. When you report, say which other methods race with it. Reviewed By: sblackshear Differential Revision: D4538793 fbshipit-source-id: 47ce700
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, boolean Annotations.FP_functionalAcrossUnboxingOk(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mBool2]
[thread-safety] don't warn on accesses to fields assigned to @Functional calls Summary: This diff adds a set of access paths holding a value returned from a method annotated with Functional to the domain. If a "functional" value is written to a field, we won't count that right as an unprotected access. The idea is to be able to use the Functional annotation to get rid of benign race false positive, such as: ``` Functional T iAlwaysReturnTheSameThing(); T mCache; T memoizedGetter() { if (mCache == null) { mCache = iAlwaysReturnTheSameThing(); } return mCache; } ``` Although there is a write-write race on `mCache`, we don't care because it will be assigned to the same value regardless of which writer wins. Reviewed By: peterogithub Differential Revision: D4476492 fbshipit-source-id: cfa5dfc
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, double Annotations.functionalDoubleBad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mDouble]
[threadsafety] read/write races Summary: Reports on reads that have one or more conflicting writes. When you report, say which other methods race with it. Reviewed By: sblackshear Differential Revision: D4538793 fbshipit-source-id: 47ce700
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, int Annotations.FP_functionalAcrossBoxingLongOk(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mBoxedLong2]
codetoanalyze/java/threadsafety/Annotations.java, int Annotations.functionalAcrossUnboxingLongBad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mLong2]
[thread-safety] don't warn on accesses to fields assigned to @Functional calls Summary: This diff adds a set of access paths holding a value returned from a method annotated with Functional to the domain. If a "functional" value is written to a field, we won't count that right as an unprotected access. The idea is to be able to use the Functional annotation to get rid of benign race false positive, such as: ``` Functional T iAlwaysReturnTheSameThing(); T mCache; T memoizedGetter() { if (mCache == null) { mCache = iAlwaysReturnTheSameThing(); } return mCache; } ``` Although there is a write-write race on `mCache`, we don't care because it will be assigned to the same value regardless of which writer wins. Reviewed By: peterogithub Differential Revision: D4476492 fbshipit-source-id: cfa5dfc
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, long Annotations.functionaLongBad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mLong]
[thread-safety] propagate attributes across binary/unary expressions Summary: Needed to handle cases like `mField = somethingFunctional() && somethingElseFunctional()` Reviewed By: peterogithub Differential Revision: D4532204 fbshipit-source-id: 078fae5
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, void Annotations.functionalAndNonfunctionalBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mInt]
[thread-safety] don't warn on methods annotated with UiThread Summary: These methods should only be called from other methods that also run on the UI thread, and they should not be starting new threads. Reviewed By: peterogithub Differential Revision: D4383133 fbshipit-source-id: 6cb2e40
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, void Annotations.mutateOffUiThreadBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.f]
[thread-safety] Add @ReturnsOwnership annotation for methods and handle it in the thread-safety analysis Reviewed By: jeremydubreil Differential Revision: D4538654 fbshipit-source-id: e5889ac
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, void Annotations.mutateSubfieldOfConfinedBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.encapsulatedField.codetoanalyze.java.checkers.Obj.f]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, void Annotations.read_from_non_confined_method_Bad(), 2, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.Annotations.zz,<Beginning of write trace>,access to codetoanalyze.java.checkers.Annotations.zz]
codetoanalyze/java/threadsafety/Annotations.java, void Annotations.read_off_UI_thread_Bad(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.Annotations.f,<Beginning of write trace>,access to codetoanalyze.java.checkers.Annotations.f]
[thread-safety] enable defining aliases of @ThreadSafe in .inferconfig Reviewed By: peterogithub Differential Revision: D4662764 fbshipit-source-id: c202509
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, void ThreadSafeAlias.threadSafeAliasBad1(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeAlias.field]
codetoanalyze/java/threadsafety/Annotations.java, void ThreadSafeAlias.threadSafeAliasBad2(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeAlias.field]
[threadsafety] Change THREAD_SAFETY_ERROR to THREAD_SAFETY_VIOLATION Summary: Change the title of the report for this kind of issue Reviewed By: sblackshear Differential Revision: D4339686 fbshipit-source-id: 673421b
8 years ago
codetoanalyze/java/threadsafety/Builders.java, Builders$Obj Builders.buildThenMutateBad(Builders$Obj), 3, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Builders$Obj.g]
codetoanalyze/java/threadsafety/Builders.java, Builders$Obj Builders.mutateBad(Builders$Obj), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Builders$Obj.g]
[thread-safety] warn on unsafe writes in constructors Reviewed By: peterogithub Differential Revision: D4437367 fbshipit-source-id: b08a5be
8 years ago
codetoanalyze/java/threadsafety/Constructors.java, Constructors Constructors.singletonBad(), 2, THREAD_SAFETY_VIOLATION, [call to Constructors.<init>(Object),access to Constructors.staticField]
codetoanalyze/java/threadsafety/Constructors.java, Constructors.<init>(), 1, THREAD_SAFETY_VIOLATION, [access to Constructors.staticField]
codetoanalyze/java/threadsafety/Constructors.java, Constructors.<init>(Constructors), 1, THREAD_SAFETY_VIOLATION, [access to Constructors.field]
[infer][thread-safety] Better error message for container writes Summary: distinguish writes via method calls (e.g., add) from writes via assignment in the error messages Reviewed By: sblackshear Differential Revision: D4611748 fbshipit-source-id: 7594d3b
8 years ago
codetoanalyze/java/threadsafety/Containers.java, void Containers.containerWrapperUnownedWriteBad(Object), 1, THREAD_SAFETY_VIOLATION, [call to Object ContainerWrapper.write(Object),call to Object ContainerWrapper._write(Object),access to container codetoanalyze.java.checkers.ContainerWrapper.children]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listAddAllBad(Collection), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mList]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listAddBad1(String), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mList]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listAddBad2(int,String), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mList]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listClearBad(), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mList]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listRemoveBad1(int), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mList]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listRemoveBad2(String), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mList]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listSetBad(int,String), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mList]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listSubclassWriteBad(ArrayList,int), 1, THREAD_SAFETY_VIOLATION, [access to container ]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapClearBad(), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mMap]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapPutAllBad(Map), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mMap]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapPutBad(String,String), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mMap]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapRemoveBad(String), 1, THREAD_SAFETY_VIOLATION, [access to container codetoanalyze.java.checkers.Containers.mMap]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapSubclassWriteBad(HashMap,String), 1, THREAD_SAFETY_VIOLATION, [access to container ]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.colocated_read_write(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,call to void DeDup.read_and_write(),access to codetoanalyze.java.checkers.DeDup.colocated_read,<Beginning of write trace>,access to codetoanalyze.java.checkers.DeDup.colocated_read]
[infer][threadsafety] Stop Unprotected Write and Read/Write races from being reported on the same line Summary: When both an unprotected write and a read/write race emanate from the same line, undoubtedly because of interprocedurality, strip the read/write report (for now). Perhaps report the info in more succinct form later, but keep to one report/line. Reviewed By: sblackshear Differential Revision: D4685102 fbshipit-source-id: 291cf20
8 years ago
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.separate_write_to_colocated_read(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.DeDup.colocated_read]
[thread-safety] move reporting of unprotected writes into aggregation function Summary: A step toward simplifying aggregation/reporting. Reviewed By: peterogithub Differential Revision: D4772207 fbshipit-source-id: 3dab2ea
8 years ago
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.twoWritesOneInCaller(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.DeDup.field]
[infer][threadsafety] Dedup, chapter 2. Summary: Stop multiple reports per line happening. These come about because of interprocedural access to multiple fields. Present one trace, and summary information about other accesses. Reviewed By: sblackshear Differential Revision: D4636232 fbshipit-source-id: 9039fea
8 years ago
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.two_fields(), 1, THREAD_SAFETY_VIOLATION, [call to void DeDup.foo(),access to codetoanalyze.java.checkers.DeDup.fielda]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.two_reads(), 3, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.DeDup.field,<Beginning of write trace>,access to codetoanalyze.java.checkers.DeDup.field]
[thread-safety] move reporting of unprotected writes into aggregation function Summary: A step toward simplifying aggregation/reporting. Reviewed By: peterogithub Differential Revision: D4772207 fbshipit-source-id: 3dab2ea
8 years ago
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.two_writes(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.DeDup.field]
[threadsafety] De-duplicate the reports Summary: Report at most one read/write race or unprotected write per access path per method Reviewed By: sblackshear, jvillard Differential Revision: D4590815 fbshipit-source-id: 3c3a9d9
8 years ago
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.write_read(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.DeDup.field]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.write_read(), 3, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.DeDup.field,<Beginning of write trace>,access to codetoanalyze.java.checkers.DeDup.field]
[threadsafety] Change THREAD_SAFETY_ERROR to THREAD_SAFETY_VIOLATION Summary: Change the title of the report for this kind of issue Reviewed By: sblackshear Differential Revision: D4339686 fbshipit-source-id: 673421b
8 years ago
codetoanalyze/java/threadsafety/Locks.java, void Locks.FP_unlockOneLock(), 4, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Locks.f]
codetoanalyze/java/threadsafety/Locks.java, void Locks.afterReentrantLockUnlockBad(), 3, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Locks.f]
codetoanalyze/java/threadsafety/Locks.java, void Locks.afterUnlockBad(), 3, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Locks.f]
codetoanalyze/java/threadsafety/Locks.java, void Locks.afterWriteLockUnlockBad(), 3, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Locks.f]
codetoanalyze/java/threadsafety/Locks.java, void Locks.lockInOneBranchBad(boolean), 4, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Locks.f]
[thread-safety] add choice variables to support partial path-sensitivity Reviewed By: peterogithub Differential Revision: D4712228 fbshipit-source-id: 50a9188
8 years ago
codetoanalyze/java/threadsafety/Locks.java, void Locks.negatedReentrantLockTryLockBad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Locks.f]
codetoanalyze/java/threadsafety/Locks.java, void Locks.tryLockNoCheckBad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Locks.f]
codetoanalyze/java/threadsafety/Locks.java, void Locks.tryLockWrongBranchBad(), 3, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Locks.f]
[thread-safety] assume formals of DI constructors are owned Reviewed By: jeremydubreil Differential Revision: D4699862 fbshipit-source-id: 1cf23b0
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, Ownership.<init>(Obj,Object), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Obj.f]
[thread-safety] add understanding of conditional ownership Summary: Previously, we would lose track of ownership in code like ``` Obj owned = new Obj(); Obj stillOwned = id(owned); // would lose ownership here stillOwned.f = ... // would report false alarm here ``` This diff partially addresses the problem by adding a notion of "unconditional" (always owned) or "conditional" (owned if some formal at index i is owned) ownership. Now we can handle simple examples like the one above. I say "partially" because we still can't handle cases where there are different reasons for conditional ownership, such as ``` oneOrTwo(Obj o1, Obj o2) { if (*) return o1; else return o2; } // we won't understand that this maintains ownership if both formals are owned Obj stillOwned = oneOrTwo(owned1, owned2); stillOwned.f = ... // we'll report a false alarm here ``` This can be addressed in the future, but will require slightly more work Reviewed By: peterogithub Differential Revision: D4520069 fbshipit-source-id: 99c7418
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.FP_ownAndConditionalOwnOk(), 3, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Obj.f]
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.FP_twoDifferentConditionalOwnsOk(), 4, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Obj.f]
[thread-safety] don't warn on writes rooted in a parameter owned by the callee Summary: In code like ``` foo() { Object local = new Object(); iWriteToAField(local); } ``` , we don't want to warn because the object pointed to by `local` is owned by the caller, then ownership is transferred to the callee. This diff supports this by introducing a notion of "conditional" and "unconditional" writes. Conditional writes are writes that are rooted in a formal of the current procedure, and they are safe only if the actual bound to that formal is owned at the call site (as in the `foo` example above). Unconditional writes are rooted in a local, and they are only safe if a lock is held in the caller. Reviewed By: peterogithub Differential Revision: D4429131 fbshipit-source-id: 2c6112b
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.cantOwnThisBad(), 1, THREAD_SAFETY_VIOLATION, [call to void Ownership.setField(Obj),access to codetoanalyze.java.checkers.Ownership.field]
[thread-safety] add callee write as protected-if if it's conditionally owned in caller Reviewed By: peterogithub Differential Revision: D4660606 fbshipit-source-id: 8e523c9
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.castThenCallBad(), 2, THREAD_SAFETY_VIOLATION, [call to void Ownership.castThenCall(Obj),call to void Subclass.doWrite(),access to codetoanalyze.java.checkers.Obj.f]
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.castThenReturnBad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Obj.f]
[thread-safety] treat constants as owned Summary: Constants are always "owned" in the sense that no one can mutate them. In code like ``` Obj getX(boolean b) { if (b) { return null; } return new Obj(); } ``` , we need to understand this in order to infer that the returned value is owned. This should fix a few FP's that I've seen. Reviewed By: peterogithub Differential Revision: D4485452 fbshipit-source-id: beae15b
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.notOwnedInCalleeBad(Obj), 1, THREAD_SAFETY_VIOLATION, [call to void Ownership.mutateIfNotNull(Obj),access to codetoanalyze.java.checkers.Obj.f]
[threadsafety] Change THREAD_SAFETY_ERROR to THREAD_SAFETY_VIOLATION Summary: Change the title of the report for this kind of issue Reviewed By: sblackshear Differential Revision: D4339686 fbshipit-source-id: 673421b
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.ownInOneBranchBad(Obj,boolean), 5, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Obj.f]
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.reassignToFormalBad(Obj), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Obj.g]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.reassignToFormalBad(Obj), 3, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.Obj.g,<Beginning of write trace>,access to codetoanalyze.java.checkers.Obj.g]
[thread-safety] don't warn on writes rooted in a parameter owned by the callee Summary: In code like ``` foo() { Object local = new Object(); iWriteToAField(local); } ``` , we don't want to warn because the object pointed to by `local` is owned by the caller, then ownership is transferred to the callee. This diff supports this by introducing a notion of "conditional" and "unconditional" writes. Conditional writes are writes that are rooted in a formal of the current procedure, and they are safe only if the actual bound to that formal is owned at the call site (as in the `foo` example above). Unconditional writes are rooted in a local, and they are only safe if a lock is held in the caller. Reviewed By: peterogithub Differential Revision: D4429131 fbshipit-source-id: 2c6112b
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.writeToNotOwnedInCalleeBad1(Obj), 1, THREAD_SAFETY_VIOLATION, [call to void Ownership.writeToFormal(Obj),access to codetoanalyze.java.checkers.Obj.f]
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.writeToNotOwnedInCalleeBad2(), 2, THREAD_SAFETY_VIOLATION, [call to void Ownership.writeToFormal(Obj),access to codetoanalyze.java.checkers.Obj.f]
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.writeToNotOwnedInCalleeBad3(Obj), 1, THREAD_SAFETY_VIOLATION, [call to void Ownership.callWriteToFormal(Obj),call to void Ownership.writeToFormal(Obj),access to codetoanalyze.java.checkers.Obj.f]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.writeToOwnedInCalleeOk2(), 4, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.Ownership.field,<Beginning of write trace>,access to codetoanalyze.java.checkers.Ownership.field]
[thread-safety] report on write outside sync, read inside sync races Summary: This was the one type of races we were not yet reporting (besides ones that use the wrong synchronization :)). Wrote new utility function to aggregate all accesses by the memory they access. This makes it easy to say which accesses we should report and what their conflicts are. Eventually, we can simplify the reporting of other kinds of unsafe accesses using this structure. Reviewed By: peterogithub Differential Revision: D4770542 fbshipit-source-id: 96d948e
8 years ago
codetoanalyze/java/threadsafety/RaceWithMainThread.java, void RaceWithMainThread.readProtectedUnthreadedBad(), 3, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.RaceWithMainThread.f]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/RaceWithMainThread.java, void RaceWithMainThread.read_unprotected_unthreaded_Bad(), 2, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.RaceWithMainThread.f,<Beginning of write trace>,access to codetoanalyze.java.checkers.RaceWithMainThread.f]
codetoanalyze/java/threadsafety/ReadWriteRaces.java, Object ReadWriteRaces.callUnprotecteReadInCallee(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,call to Object ReadWriteRaces.unprotectedReadInCallee(),access to codetoanalyze.java.checkers.ReadWriteRaces.field1,<Beginning of write trace>,access to codetoanalyze.java.checkers.ReadWriteRaces.field1]
codetoanalyze/java/threadsafety/ReadWriteRaces.java, Object ReadWriteRaces.unprotectedRead1(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ReadWriteRaces.field1,<Beginning of write trace>,access to codetoanalyze.java.checkers.ReadWriteRaces.field1]
codetoanalyze/java/threadsafety/ReadWriteRaces.java, Object ReadWriteRaces.unprotectedRead2(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ReadWriteRaces.field2,<Beginning of write trace>,access to codetoanalyze.java.checkers.ReadWriteRaces.field2]
codetoanalyze/java/threadsafety/ReadWriteRaces.java, Object ReadWriteRaces.unprotectedRead3(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ReadWriteRaces.field3,<Beginning of write trace>,call to void ReadWriteRaces.syncWrite3(),access to codetoanalyze.java.checkers.ReadWriteRaces.field3]
codetoanalyze/java/threadsafety/ReadWriteRaces.java, void ReadWriteRaces.m1(), 2, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ReadWriteRaces.racy,<Beginning of write trace>,access to codetoanalyze.java.checkers.ReadWriteRaces.racy]
[threadsafety] read/write races Summary: Reports on reads that have one or more conflicting writes. When you report, say which other methods race with it. Reviewed By: sblackshear Differential Revision: D4538793 fbshipit-source-id: 47ce700
8 years ago
codetoanalyze/java/threadsafety/ReadWriteRaces.java, void ReadWriteRaces.m2(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ReadWriteRaces.racy]
codetoanalyze/java/threadsafety/ReadWriteRaces.java, void ReadWriteRaces.m3(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ReadWriteRaces.racy]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/ReadWriteRaces.java, void ReadWriteRaces.readInCalleeOutsideSyncBad(int), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,call to int C.get(),access to codetoanalyze.java.checkers.C.x,<Beginning of write trace>,call to void C.set(int),access to codetoanalyze.java.checkers.C.x]
[threadsafety] Change THREAD_SAFETY_ERROR to THREAD_SAFETY_VIOLATION Summary: Change the title of the report for this kind of issue Reviewed By: sblackshear Differential Revision: D4339686 fbshipit-source-id: 673421b
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ExtendsThreadSafeExample.newmethodBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ExtendsThreadSafeExample.field]
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ExtendsThreadSafeExample.tsOK(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ExtendsThreadSafeExample.field]
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ThreadSafeExample.callPublicMethodBad(), 1, THREAD_SAFETY_VIOLATION, [call to void ThreadSafeExample.assignInPrivateMethodOk(),access to codetoanalyze.java.checkers.ThreadSafeExample.f]
[thread-safety] don't consider VisibleForTesting methods as public Summary: We warn on unsafe accesses to fields that occur in a public method (or are reachable from a public method). We ought not to consider VisibleForTesting methods as public, since they are only public for testing purposes. Reviewed By: peterogithub Differential Revision: D4477648 fbshipit-source-id: 5f58914
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ThreadSafeExample.callVisibleForTestingBad(), 1, THREAD_SAFETY_VIOLATION, [call to void ThreadSafeExample.visibleForTestingNotPublicOk(),access to codetoanalyze.java.checkers.ThreadSafeExample.f]
[threadsafety] Change THREAD_SAFETY_ERROR to THREAD_SAFETY_VIOLATION Summary: Change the title of the report for this kind of issue Reviewed By: sblackshear Differential Revision: D4339686 fbshipit-source-id: 673421b
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ThreadSafeExample.deeperTraceBad(), 1, THREAD_SAFETY_VIOLATION, [call to void ThreadSafeExample.callAssignInPrivateMethod(),call to void ThreadSafeExample.assignInPrivateMethodOk(),access to codetoanalyze.java.checkers.ThreadSafeExample.f]
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ThreadSafeExample.oddBad(), 1, THREAD_SAFETY_VIOLATION, [call to void ThreadSafeExample.evenOk(),access to codetoanalyze.java.checkers.ThreadSafeExample.f]
[infer][ondemand] run all the registered checkers in sequence Summary: Run all the checkers one after each other, which allows the Infer AI framework to run several checkers together, including the possibility for them to collaborate. Reviewed By: sblackshear Differential Revision: D4621838 fbshipit-source-id: e264d67
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ThreadSafeExample.recursiveBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeExample.f]
[threadsafety] Change THREAD_SAFETY_ERROR to THREAD_SAFETY_VIOLATION Summary: Change the title of the report for this kind of issue Reviewed By: sblackshear Differential Revision: D4339686 fbshipit-source-id: 673421b
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ThreadSafeExample.tsBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeExample.f]
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void YesThreadSafeExtendsNotThreadSafeExample.subsubmethodBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.YesThreadSafeExtendsNotThreadSafeExample.subsubfield]
[thread-safety] report both a read and write stack trace in R/W race reports Summary: This should make the reports much easier to understand. We can generalize to reporting a stack trace for all of the writes in the future if we wish. Reviewed By: peterogithub Differential Revision: D4845641 fbshipit-source-id: 589fdbc
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, Object ThreadSafeMethods.readSameFieldAsThreadSafeMethod1Bad(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ThreadSafeMethods.field1,<Beginning of write trace>,access to codetoanalyze.java.checkers.ThreadSafeMethods.field1]
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, Object ThreadSafeMethods.readSameFieldAsThreadSafeMethod2Bad(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ThreadSafeMethods.field4,<Beginning of write trace>,access to codetoanalyze.java.checkers.ThreadSafeMethods.field4]
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, Object ThreadSafeMethods.readSameFieldAsThreadSafeMethod3Bad(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ThreadSafeMethods.field5,<Beginning of write trace>,access to codetoanalyze.java.checkers.ThreadSafeMethods.field5]
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, Object ThreadSafeMethods.threadSafeMethodReadBad(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ThreadSafeMethods.field2,<Beginning of write trace>,access to codetoanalyze.java.checkers.ThreadSafeMethods.field2]
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, Object ThreadSafeMethodsSubclass.readThreadSafeFieldOfOverrideBad(), 1, THREAD_SAFETY_VIOLATION, [<Beginning of read trace>,access to codetoanalyze.java.checkers.ThreadSafeMethodsSubclass.subclassField,<Beginning of write trace>,access to codetoanalyze.java.checkers.ThreadSafeMethodsSubclass.subclassField]
[thread-safety] tests for thread-safe methods Summary: No new functionality here; mostly `FN_` tests documenting our current limitations. Will start chipping away at the false negatives in follow-up diffs. Reviewed By: peterogithub Differential Revision: D4780013 fbshipit-source-id: 7a0c821
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, void ThreadSafeMethods.threadSafeMethodWriteBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeMethods.field1]
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, void ThreadSafeMethods.threadSafePrivateMethodBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeMethods.field2]
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, void ThreadSafeMethods.threadSafeVisibleForTestingMethodBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeMethods.field3]
[thread-safety] report more warnings by inferring when state is accessed by methods marked `@ThreadSafe` and other methods. Summary: If two public methods touch the same state and only one is marked `ThreadSafe`, it's reasonable to report unsafe accesses on both of them. Reviewed By: peterogithub Differential Revision: D4785038 fbshipit-source-id: 5a80da4
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, void ThreadSafeMethods.writeSameFieldAsThreadSafeMethod1Bad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeMethods.field1]
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, void ThreadSafeMethods.writeSameFieldAsThreadSafeMethod2Bad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeMethods.field4]
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, void ThreadSafeMethods.writeSameFieldAsThreadSafeMethod3Bad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeMethods.field5]
[thread-safety] tests for thread-safe methods Summary: No new functionality here; mostly `FN_` tests documenting our current limitations. Will start chipping away at the false negatives in follow-up diffs. Reviewed By: peterogithub Differential Revision: D4780013 fbshipit-source-id: 7a0c821
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, void ThreadSafeMethodsSubclass.safeMethodOverride(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeMethodsSubclass.subclassField]
[thread-safety] report more warnings by inferring when state is accessed by methods marked `@ThreadSafe` and other methods. Summary: If two public methods touch the same state and only one is marked `ThreadSafe`, it's reasonable to report unsafe accesses on both of them. Reviewed By: peterogithub Differential Revision: D4785038 fbshipit-source-id: 5a80da4
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeMethods.java, void ThreadSafeMethodsSubclass.writeThreadSafeFieldOfOverrideBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeMethodsSubclass.subclassField]