github / codeql-cli-binaries

Binaries for the CodeQL CLI
Other
741 stars 105 forks source link

When I execute the following query in LGTM and running it locally, I will be stuck at 61%, and the execution will fail later #117

Closed ernongxizhu closed 2 years ago

ernongxizhu commented 2 years ago

codeql database:Uranusboy/log4j2-test url:https://lgtm.com/projects/g/Uranusboy/log4j2-test/alerts/?mode=list

When I execute the following query in LGTM, I will be stuck at 61%, and the execution will fail later.

I also tried it locally, and it will get stuck. I hope someone can try to run c.ql iteration 414 of DataFlowImpl::FlowExploration::revPartialPathSetp#ffffffffb etc

import java
import semmle.code.java.dataflow.FlowSources
import DataFlow::PathGraph
class Context extends  RefType{
    Context(){
        this.hasQualifiedName("javax.naming", "Context")
        or
        this.hasQualifiedName("javax.naming", "InitialContext")
    }
}

predicate isLookup(Expr arg) {
    exists(MethodAccess ma |
        ma.getMethod().getName() = "lookup"
        and
        ma.getMethod().getDeclaringType() instanceof Context
        and
        arg = ma.getArgument(0)
    )
}

class TainttrackLookup  extends TaintTracking::Configuration {
    TainttrackLookup() { 
        this = "TainttrackLookup" 
    }

    override predicate isSource(DataFlow::Node source) { none() }
    override predicate isSink(DataFlow::Node sink) {
        exists(Expr arg |
            isLookup(arg)
            and
            sink.asExpr() = arg
        )
    }
    override int explorationLimit() { result = 17 }
} 
from TainttrackLookup config, DataFlow::PartialPathNode sink,DataFlow::PartialPathNode node
where 
    config.hasPartialFlowRev(node,sink,17)
select sink.getNode(),node.getNode()

When the explorationlimit is less than 4, it is normal,

tausbn commented 2 years ago

As mentioned in my response to the other issue you raised, it's likely that 17 is too high of a limit. In general, materialising the entire graph is infeasible, and the same is true when you set a high explorationLimit.

I'm slightly confused, though. You say it works fine with a limit of 4, but doesn't terminate (or times out) with a limit of 17. What about the values 5 through 16?

ernongxizhu commented 2 years ago

As mentioned in my response to the other issue you raised, it's likely that 17 is too high of a limit. In general, materialising the entire graph is infeasible, and the same is true when you set a high explorationLimit.

I'm slightly confused, though. You say it works fine with a limit of 4, but doesn't terminate (or times out) with a limit of 17. What about the values 5 through 16?

Thank you very much for your answer.

Thank you very much for your answer. It will also timeout when the value is 5. Strangely, I will be very slow when running locally. My computer is configured with 8 cores and 16g memory. And it is very obvious that the occupancy rate is not very high