Open xpcmdshell opened 4 years ago
Thank you for your issue report.
Looking at the report above I suggest the following steps:
realpath
and not a symlink.I have successfully done a CodeQL managed build using Xcode installed in /Applications/Xcode.app
using latest WebKit.git master and CodeQL CLI Binaries version 2.1.0 with the command line you provided:
codeql database create /tmp/db --language=cpp --command="./Tools/Scripts/build-webkit --jsc-only --debug"
/tmp/db ends up being about 2.8GB in size.
If you have any further questions please feel free to ask.
Hi, thanks for checking out my issue. I'm still seeing the same errors about libptrace.dylib
not being injected into platform binaries. Using Xcode from /Applications
doesn't seem to help. What version of MacOS are you using to test this, out of curiosity?
My database after generation for latest commit of webkit is also about 2.8GB, so maybe there's nothing significant missing 🙂
sw_vers
reports:
ProductName: Mac OS X
ProductVersion: 10.15.4
BuildVersion: 19E287
xcodebuild -version
reports:
Xcode 11.1
Build version 11A1027
Another thing to try (along with using Xcode in /Applications) is to put the database in /tmp when creating it (the directory can be relocated afterwards).
If that still fails I would appreciate a copy of
Same thing with creating the database in /tmp/
🤔
Here's a copy of my logs, let me know if there's anything else I can provide to be helpful: https://drive.google.com/open?id=1Gm-lQIV0sNOCt863esjjm6Ayv9rxx2_5
Thank you for these. I have taken local copies - so don't feel the need to preserve them in your Google Drive.
The good news is that from the database create log I think the vast majority of the build is being processed correctly - so the database should be usable.
Unfortunately I don't have a solution to the problem you've been having yet. I need to do some further investigations locally, and this will take some time.
Sounds good, thanks for taking a look into this
Any update on this?
Much code regarding build instrumentation on MacOS has changed recently as part of getting tracing on M1 to work. Is this issue still live?
Description
During database creation for compiled languages, it looks like CodeQL tries to add some instrumentation to your compiler to get more info. This fails for "platform binaries" on OSX, which are protected from
DYLD_INSERT_LIBRARIES
as well astask_for_pid
and friends. For example, below I'm attempting to create a database for a particular revision of WebKit:You can see above the lines about
libtrace.dylib
injection failing, specifically:Disabling SIP doesn't appear to work around this, the outcome is the same. This is one example that under the hood probably uses things like
xcodebuild
andclang
.Database creation "finishes", but it's unclear how much information is actually missing. I actually don't know what all CodeQL tries to gather from the compilation process. How messed up will my database be if instrumentation fails during the build step?