I tried to reproduce @Beeram12's work on a larger computer (56 cores, 2.5Ghz, 128 GB RAM). I configured with 50 threads and 32GB RAM. It ran overnight. top showed this for java when I killed it:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND  
3324489 joel      20   0   40.7g  20.2g 240348 S 161.2  16.1 931:56.24 java   

java is about 16 hours of CPU time there. The database is huge and at 236GB is too large to transfer in a reasonable length of time. Especially from hotel wifi.

$ du -s -h rtems-db/*
236G	rtems-db/cpp
8.0K	rtems-db/diagnostic
60M	rtems-db/log
15M	rtems-db/python
2.6M	rtems-db/working

I have attached the nohup_out.txt in case that helps any.

I am on travel this week but will report on the smaller test case if @Beeram12 doesn't beat me to it.

@smowton
I ran queries for Python language it worked well, and I reported as well, but it's not the case for c/cpp packages

@Beeram12 thanks for sharing-- unfortunately I'm unable to download it from Google Drive. Could you please try--

1. Prior to upload, delete the log and results directories which seem to be very large, and run codeql database cleanup --cache-cleanup=clear.
2. Please upload a zip file, as Google Drive struggles to zip up such a large object server-side.

Thanks for sharing the pared-down database; I was able to reproduce and make a candidate fix: github/codeql-coding-standards#907

That fix is queued to merge; the next release should resolve the issue and avoid needing to exclude that query.