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

53 lines
9.7 KiB
Raw Normal View History Unescape

[thread-safety] propagate @Functional attribute across boxing of primitive types Reviewed By: jeremydubreil Differential Revision: D4501552 fbshipit-source-id: c4cc9ec
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, boolean Annotations.FP_functionalAcrossUnboxingOk(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mBool]
[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]
[thread-safety] propagate @Functional attribute across boxing of primitive types Reviewed By: jeremydubreil Differential Revision: D4501552 fbshipit-source-id: c4cc9ec
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, long Annotations.FP_functionalAcrossBoxingLongOk(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mBoxedLong]
[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 @Functional attribute across boxing of primitive types Reviewed By: jeremydubreil Differential Revision: D4501552 fbshipit-source-id: c4cc9ec
8 years ago
codetoanalyze/java/threadsafety/Annotations.java, long Annotations.functionalAcrossUnboxingLongBad(), 2, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Annotations.mLong]
[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] support fields annotated with @ThreadConfined Summary: Similar to marking classes ThreadConfined, we want to support marking fields as well. The intended semantics are: don't warn on writes to the marked field outside of syncrhonization, but continue to warn on accesses to subfields. Reviewed By: peterogithub Differential Revision: D4406890 fbshipit-source-id: af8a114
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.Annotations$Obj.fld]
[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]
[thread-safety] support conditional writes to containers Reviewed By: jeremydubreil Differential Revision: D4544815 fbshipit-source-id: a96d074
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 codetoanalyze.java.checkers.ContainerWrapper.children.add]
[thread-safety] warn on unsafe accesses to lists Summary: Simple model for List methods that write to the collection. Reviewed By: peterogithub Differential Revision: D4453381 fbshipit-source-id: 19edc51
8 years ago
codetoanalyze/java/threadsafety/Containers.java, void Containers.listAddAllBad(Collection), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mList.addAll]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listAddBad1(String), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mList.add]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listAddBad2(int,String), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mList.add]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listClearBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mList.clear]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listRemoveBad1(int), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mList.remove]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listRemoveBad2(String), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mList.remove]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listSetBad(int,String), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mList.set]
codetoanalyze/java/threadsafety/Containers.java, void Containers.listSubclassWriteBad(ArrayList,int), 1, THREAD_SAFETY_VIOLATION, [access to remove]
[thread-safety] warn on unsafe accesses to maps Summary: Adding models that allow us to warn on unguarded accesses to subclasses of `Map`, but not on accesses of threadsafe containers like `ConcurrentMap`. Lots more containers to model later, but stopping at `Map`s for now to make sure the approach looks ok. Reviewed By: jvillard Differential Revision: D4385306 fbshipit-source-id: d791eee
8 years ago
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapClearBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mMap.clear]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapPutAllBad(Map), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mMap.putAll]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapPutBad(String,String), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mMap.put]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapRemoveBad(String), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.Containers.mMap.remove]
codetoanalyze/java/threadsafety/Containers.java, void Containers.mapSubclassWriteBad(HashMap,String), 1, THREAD_SAFETY_VIOLATION, [access to remove]
[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 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] 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] 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] 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]
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ThreadSafeExample.recursiveBad(), 1, THREAD_SAFETY_VIOLATION, [access to codetoanalyze.java.checkers.ThreadSafeExample.f]
codetoanalyze/java/threadsafety/ThreadSafeExample.java, void ThreadSafeExample.recursiveBad(), 2, THREAD_SAFETY_VIOLATION, [call to void ThreadSafeExample.recursiveBad(),access to codetoanalyze.java.checkers.ThreadSafeExample.f]
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]