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

36 lines
6.5 KiB
Raw Normal View History Unescape

[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] 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] allow ownership to be transferred via return Summary: Previously, we would correctly be silent on code like `x = new T(); x.f = ...`, but would wrongly warn on code like `x = makeT(); x.f = ...`. The reason is that we only allowed ownership through direct allocation. This diff adds a boolean that specifies whether the return value is owned as part of the summary. This allows us to correctly handle many common cases of (transitively) returning a freshly allocated object, but still won't work for understanding that ownership is maintained in examples like `x = new T(); y = id(x); y.f = ...`. Reviewed By: jvillard Differential Revision: D4456864 fbshipit-source-id: b5eec02
8 years ago
codetoanalyze/java/threadsafety/Ownership.java, void Ownership.FP_passOwnershipInIdFunctionOk(), 3, 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]
[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]
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]