Closed ernongxizhu closed 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?
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
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
When the
explorationlimit
is less than 4, it is normal,