Qodana Process Stuck in Gitlab

[esafirm]

Hi team,

We're currently using Qodana JVM Android Community edition in our Gitlab pipeline for detecting Kotlin UnusedSymbol

After upgrade to 2023.1-eap to support new AGP version, Qodana process seems to be stuck analyzing the code at certain percentage. Here's the log:

Keep running Project analysis ... so far 30s
Analyzing code 1%
Analyzing code 1%
Analyzing code 2%
Keep running Project analysis ... so far 1m
Keep running Project analysis ... so far 1m 30s
Analyzing code 3%
Keep running Project analysis ... so far 2m
Keep running Project analysis ... so far 2m 30s
Keep running Project analysis ... so far 3m
Analyzing code 4%
Analyzing code 5%
Analyzing code 5%
Keep running Project analysis ... so far 3m 30s
Analyzing code 6%
Keep running Project analysis ... so far 4m
Analyzing code 7%
Analyzing code 8%
Keep running Project analysis ... so far 4m 30s
Analyzing code 9%
Keep running Project analysis ... so far 5m
Keep running Project analysis ... so far 5m 30s
Keep running Project analysis ... so far 6m
Keep running Project analysis ... so far 6m 30s
Keep running Project analysis ... so far 7m
Keep running Project analysis ... so far 7m 30s
Keep running Project analysis ... so far 8m
Keep running Project analysis ... so far 8m 30s
Keep running Project analysis ... so far 9m

Until timeout in 1 hour, we actually try set it to 2 hour but no luck

I assume this is something to do with memory, because scoping down the analysis to certain directories only works in less than 15 minutes on the same runner.

Unfortunately I cannot find any documentation regarding the memory configuration or anything for process stuck like this, we can even find the IDE log (?)

And the question would be, how we can resolve this?

Thank you in advance.

[brichbash]

Hello,

Could you please tell what runners you use and their specs?
I managed to reproduce the problem on a GitLab-hosted runner saas-linux-small-amd64 with 3.75gb RAM, but using saas-linux-medium-amd64 with 8gb RAM resolved the issue.

[esafirm]

In that case, timeout command should help, right?

Let's say I got a way to save an artifact. What and where should I look for this log?

[brichbash]

Let's say I got a way to save an artifact. What and where should I look for this log?

Logs are stored under the directory specified in --results-dir in log folder. I think you can just upload the specified results-dir as an artifact and then share log directory from it at [email protected].

In that case, timeout command should help, right?

I'm not sure. For instance, after running:

 script:
   - timeout --preserve-status 180 qodana --results-dir=$CI_PROJECT_DIR/qodana --save-report --report-dir=$CI_PROJECT_DIR/qodana/report

GitLab still won't upload the artifact

[esafirm]

Hi @brichbash, our team just revisiting this issue again since we want to use our dead code remover again.

We were able to run the timeout and preserve the log by running:

timeout <duration> qodana  --results-dir=$CI_PROJECT_DIR/qodana --save-report --report-dir=$CI_PROJECT_DIR/qodana/report || true

Since we need to a clearance to share the log first, can you tell me what exactly did you want to check?

I already check idea.log which have the original message in their tail, the Gradle import log also indicate that the process was a success.

We do have multiple thread dump text files though

[brichbash]

Please share all the thread dumps and idea.log. You can send them to [email protected].

[esafirm]

Hi @brichbash , I sent the thread dumps and the log to the email above. Thanks