Build-wrapper-dump.json does not contain information about translation units

  • using build-wrapper version 6.15 (macosx-x86)
    The build wrapper is executed on an xcodebuild command from an Azure Devops build pipeline on a Microsoft hosted MacOS 10.15 agent.
    The generated build-wrapper-dump.json file does not contain information about the files that were built by the build command.
    This results in java.lang.IllegalStateException: The “build-wrapper-dump.json” file was found but 0 C/C++/Objective-C files were analyzed. when executing the scanner

If the same build pipeline is executed on a different machine it works without problems

Hi @AngelaSt,

could you share the logs of the build, the analysis, and the content of the build-wrapper output dir? If you cannot do it publicly I can send you a private message.

Please send private message

@AngelaSt, could you post the comparison detail between the working and failing machines, including the difference in the OS kernel? It doesn’t seem like that should matter for this, but it could be helpful.

As we discussed, I’m not able to access the private thread, so unless there’s a way to grant me access, maybe you could start a new one that includes me and @mpaladin? Otherwise we can confer offline and I can continue on your behalf. Thanks.

The “bad” machine has Release: 19.6.0 Version: Darwin Kernel Version 19.6.0: Mon Apr 12 20:57:45 PDT 2021; root:xnu-6153.141.28.1~1/RELEASE_X86_64 Machine: x86_64
The “good” one has Release: 19.6.0 Version: Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 Machine: x86_64

@mpaladin, do you see anything in the logs or system comparison that might explain the issue?

A similar issue was reported in Sonar-scanner fails to scan C code, though the environment is different, not to mention running in Docker. @mpaladin, with regard to the solution there, might there be a command we can use for additional debugging?

I removed the timestamps from the successful and failing logs to try to further isolate where/how things are going wrong. The good log has several instances of compiler probing that are missing from the bad log, but this probably doesn’t tell us anything new. I’ll see if I can attach the logs in a private chat.

Hi @Webb ,

it has nothing to do with that.

build-wrapper stops following processes after RegisterExecutionPolicyException step in the build.

My best guess is that something is wrong with SIP and OS security features, however, I would need more details or a reproducer to better understand.

Thanks @mpaladin. I’ve logged a support ticket in the Microsoft developer community. Let’s leave this ticket open for now if that’s OK.

Hi @Webb ,

I am not sure you are going to get a solution from there.

Are you able to reproduce it with a small reproducer project on an Azure DevOps agent? That would help.

Interesting… I applied the same configuration to one of our smaller iOS projects, and the analyze task works after the wrapper build on an ADO-hosted Mac agent. So we have a functional precedent, though I’m actually not sure if the code in the smaller project really contains a mix of languages (would this matter?).

Hi @Webb ,

are you able to provide a reproducing project?

Hi @mpaladin, I can check if someone on the development team would be able to create a generic, mixed-language project for testing, but I’m not sure when this could be done. And matters are less certain now that we have another project that does not have the issue, though again I don’t know if it has a mix of languages.

Do you have access to Azure-hosted build agents?

Hi @Webb ,

if you are referring to Microsoft-hosted agents for Azure Pipelines - Azure Pipelines | Microsoft Learn the answer is yes, it would be perfect if you would have a reproducer that fails on Azure agent.

Hi @mpaladin, FYI we resolved the issue by using a build target that only builds the sources. The original target did some additional tasks that must have somehow caused the problem. This ticket can be closed.

Hi @Webb ,

thank you for the update. What kind of tasks were causing the problem?