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

81 lines
14 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] 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 ]
[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.colocated_read_write(), 1, THREAD_SAFETY_VIOLATION, [call to void DeDup.read_and_write(),access to codetoanalyze.java.checkers.DeDup.colocated_write]
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.separate_write_to_colocated_read(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.DeDup.colocated_read]
[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.twoWritesOneInCaller(), 1, THREAD_SAFETY_VIOLATION, [call to void DeDup.writeToField(),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]
[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.two_reads(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.DeDup.field]
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.two_writes(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.DeDup.field]
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.write_read(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.DeDup.field]
codetoanalyze/java/threadsafety/DeDup.java, void DeDup.write_read(), 3, THREAD_SAFETY_VIOLATION, [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]
[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/Ownership.java, void Ownership.reassignToFormalBad(Obj), 3, THREAD_SAFETY_VIOLATION, [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]
[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/Ownership.java, void Ownership.writeToOwnedInCalleeOk2(), 4, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Ownership.field]
[threadsafety] Races and non-races involving assertMainThread(). Reviewed By: sblackshear Differential Revision: D4721971 fbshipit-source-id: c1dfb19
8 years ago
codetoanalyze/java/threadsafety/RaceWithMainThread.java, void RaceWithMainThread.read_unprotected_unthreaded_Bad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.RaceWithMainThread.f]
[thread-safety] give full traces for read/write races Summary: Before, `trace_of_pname` only grabbed unprotected writes from the summary, so the traces ending in an unprotected read were truncated. We now look at reads too when appropriate. Reviewed By: peterogithub Differential Revision: D4719740 fbshipit-source-id: 28f6e63
8 years ago
codetoanalyze/java/threadsafety/ReadWriteRaces.java, Object ReadWriteRaces.callUnprotecteReadInCallee(), 1, THREAD_SAFETY_VIOLATION, [call to Object ReadWriteRaces.unprotectedReadInCallee(),access to codetoanalyze.java.checkers.ReadWriteRaces.field1]
[thread-safety] report on protected write/unprotected read races Summary: Previously, we wouldn't report races where the write was under synchronization. Reviewed By: peterogithub Differential Revision: D4658850 fbshipit-source-id: e9f4c41
8 years ago
codetoanalyze/java/threadsafety/ReadWriteRaces.java, Object ReadWriteRaces.unprotectedRead1(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ReadWriteRaces.field1]
codetoanalyze/java/threadsafety/ReadWriteRaces.java, Object ReadWriteRaces.unprotectedRead2(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ReadWriteRaces.field2]
codetoanalyze/java/threadsafety/ReadWriteRaces.java, Object ReadWriteRaces.unprotectedRead3(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ReadWriteRaces.field3]
[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.m1(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ReadWriteRaces.racy]
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] classify protected-if reads/writes in callees as protected when a lock is held in the caller Summary: Fixes bug pointed out by ilyasergey, thanks! Reviewed By: peterogithub Differential Revision: D4736873 fbshipit-source-id: f4be32a
8 years ago
codetoanalyze/java/threadsafety/ReadWriteRaces.java, void ReadWriteRaces.readInCalleeOutsideSyncBad(int), 1, THREAD_SAFETY_VIOLATION, [call to int C.get(),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]
[thread-safety] add and support @ThreadSafeMethod annotation Reviewed By: jeremydubreil Differential Revision: D4411223 fbshipit-source-id: 55b0a6b
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void NonThreadSafeClass.threadSafeMethod(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.NonThreadSafeClass.field]
[thread-safety] warn on unsafe accesses in overrides of methods annotated with @ThreadSafeMethod Reviewed By: jeremydubreil Differential Revision: D4439591 fbshipit-source-id: 268890b
8 years ago
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void NonThreadSafeSubclass.safeMethod(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.NonThreadSafeClass.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/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]