Open 18Fl opened 1 year ago
@jketema hey, I report it at here. thank u!
Thanks for the report. Looking at the build-tracer.log
file, which is included with the database, tt seems that some of the extractor processes either crash or get killed. This leaves some incomplete brotli files that can then not be parsed later during database finalisation. It's unfortunately not clear from the logs why this is happening.
Thanks for the report. Looking at the
build-tracer.log
file, which is included with the database, tt seems that some of the extractor processes either crash or get killed. This leaves some incomplete brotli files that can then not be parsed later during database finalisation. It's unfortunately not clear from the logs why this is happening.
would u will fix this? and what can I do? thx.
would u will fix this? and what can I do? thx.
This is a bit difficult, as the logs don't provide much evidence. One thing you could maybe help me with to check whether the Windows Event Viewer shows any events that might explain why the extractor processes either crashed or killed.
Introduction
Hey, This is a separate bug from https://github.com/github/codeql/issues/13552. when I try to slove the old bug. I want to see if it is a platform specific problem . so I use wsl ubuntu on windows do another test. and found this bug.
Here is my chormium version:
and the args.gn is simple:
and ubuntu version:
when we compile chrome by this command:
now bug happened. I split it into 2 cases. the first one is normal. but second one is the bug. but I think I list the 2 cases will help us found the bug.
and I tried codeql differenct version:
case 00
case 00 is normal. when we finish the chrome build. we delete the file
then we create codeql database by this:
I could confirm the codeql database create successfully. here is the snip(original log is too long...):
we use this simple case to help us query:
u could see everything works well.
This is a normal case, but I still offer the codeql database(you could see in boom.zip) , then you could diff with unnormal case. boom.zip
case 01
now we reproduce the unnormal case, jut compile full chrome like before. then we delete the all .o file in out/codeql/obj/content/browser/browser.
note that we don't need "gn gen out/codeql" again, becasue this folder only have *.o file. so it's ok(even u use "gn gen ..." it will still failed... I have tried).
then we still use this to create codeql database file:
now this time you will see these log:
It means we meet some error, but the database create successfully.
But when we try still try to run this query, it will failed:
In my personal views, seems it doesn't link handler file into the database. If u view the AST. u can't got nothing. but normal case(boom.zip) u could view right ast.
I attahch the database . you could see the log in the database.
my inverstigate
I inversitigate it a little, maybe I am wrong. but I still offer it maybe it will help u.
First, I suspect maybe it is because of my space is not enough. In my personal views. codeql create database. and zip it. but if it found the space is not enough before zip the database, it won't failed, it just abandon some information. and zip it could zip file.
So I use this command to inverstigate:
It shows that the maximium size is 11G, but my available space is 200G. So I don't think is this reason.
Second, I found a similar case in https://github.com/github/codeql/issues/7582. But the problem is fixed. I think this is a similar case... when codeql extract some specific c++ code, it will failed... think about this, If I just recompile input_handler.o it will success, but if I recompile input_handler.o and another file. I will failed. So I think the problem is in the another file. This is too hard for me, but I think If u see the .log file. your could know what happened.
repro.zip