Defunct process while using build-wrapper together with qbs

SonarQube Cloud
1

Environment:

  • SonarQube build-wrapper 6.59
  • Qt Qbs 2.1.2
  • Ubuntu 22.04 based docker container

Goal: we try to integrate the usage of SonarQube into our build process. Part of the build process is running sth like

/opt/SonarQube/build-wrapper/build-wrapper-linux-x86-64 \
        --out-dir /home/builduser/builddir/target/build/reports/QBS-2.1.2-linux64-gcc-qt6-5-6-release/sonar_result_folder \
        python3 start_something.py script /home/builduser/builddir/target/build/generated.bscript \
                --showcommandline \
                --build-dir /home/builduser/builddir/target/build \
                -t linux64-gcc-qt6-5-6 \
                -c release \
                project.coverageBuild:false \
                project.developerBuild:false project.withTests:false \
                -u -x

The python script performs - among other things - tool chain detection and then starts the Qbs based build process.

At some point the build process hangs; we face the following process tree (part output of ps -af):

\_ /bin/bash /<some path>/script.sh.copy
    \_ /opt/SonarQube/build-wrapper/build-wrapper-linux-x86-64 --out-dir /home/builduser/builddir/target/build/reports/QBS-2.1.2-linux64-gcc-qt6-5-6-release/sonar_result_folder python3 start_something.py script /home/builduser/builddir/target/build/generated.bscript --showcommandline --build-dir /home/builduser/builddir/target/build -t linux64-gcc-qt6-5-6 -c release project.coverageBuild:false project.developerBuild:false project.withTests:false -u -x
    |   \_ /opt/SonarQube/build-wrapper/build-wrapper-linux-x86-64 -c python3 start_something.py script /home/builduser/builddir/target/build/generated.bscript --showcommandline --build-dir /home/builduser/builddir/target/build -t linux64-gcc-qt6-5-6 -c release project.coverageBuild:false  project.developerBuild:false project.withTests:false -u -x
    |       \_ python3 start_something.py script /home/builduser/builddir/target/build/generated.bscript --showcommandline --build-dir /home/builduser/builddir/target/build -t linux64-gcc-qt6-5-6 -c release project.coverageBuild:false project.developerBuild:false project.withTests:false -u -x
    |           \_ /bin/sh -c /home/builduser/QtCreator/11.0.8/bin/qbs build --settings-dir /home/builduser/.config/Qbs/2.1.2 --build-directory /home/builduser/builddir/target/build --file /home/builduser/scm/src/apps/<someapp>/something.sln.qbs --command-echo-mode command-line config:linux64-gcc-qt6-5-6-release profile:linux64-gcc-qt6-5-6
    |               \_ /home/builduser/QtCreator/11.0.8/bin/qbs build --settings-dir /home/builduser/.config/Qbs/2.1.2 --build-directory /home/builduser/builddir/target/build --file /home/builduser/scm/src/apps/xyz/xyz.sln.qbs --command-echo-mode command-line config:linux64-gcc-qt6-5-6-release profile:linux64-gcc-qt6-5-6
    |                   \_ /home/builduser/QtCreator/11.0.8/bin/../libexec/qtcreator/qbs_processlauncher /tmp/qbs_processlauncher-342
    |                       \_ [x86_64-linux-gn] <defunct>

I need to capture the proc maps for the qbs_processlauncher process next time.

2

Hi,

What’s your version of SonarQube? Check the page footer if you’re not sure. And can you verify that the version of the build-wrapper you’re using is from that version of SonarQube?

 
Thx,
Ann

3

Hi,

I’ve been told a few minutes ago that it’s a good idea to differentiate between SonarQube and SonarCloud. So my fault might have been that I’m stating “SonarQube” when in reality I mean “SonarCloud”. Sorry …

Based on that … I’ve downloaded the build-wrapper from

https://sonarcloud.io/static/cpp/build-wrapper-linux-x86.zip

This gives me 6.59.

I have some sonar-scanner installed inside my docker image as well. That is 5.0.1.3006 - dated from August 2023.
The build-wrapper executable is located at /opt/SonarQube/build-wrapper/build-wrapper-linux-x86-64.
The sonar-scanner executable is located at /opt/SonarQube/sonar-scanner-5.0.1.3006/bin.

Is build-wrapper already trying to use parts of the sonar-scanner folder??? I thought that build-wrapper needs to complete successfully on its own and then one can call sonar-scanner ?

Inside the sonar-scanner folder there is no separate build-wrapper; so I’m not sure what you mean with “the version of the build-wrapper you’re using is from that version of SonarQube” ?
How do I check?

You should consider my misunderstanding wrt. terms “SonarQube” and “SonarCloud” …

Thanks!

4

Hi,

It’s helpful to know that you’re on SonarCloud. I’ve moved this thread to that category.

Perfect.

This is not the latest version, and you should consider upgrading, but it’s likely not the cause of your current problem.

No

Yes, this is how it works.

I’m going to flag this for the language experts.

 
Ann

7

Hello @HeikoNardmann and welcome to the community,

In the specified --out-dir for the build-wrapper command (/home/builduser/builddir/target/build/reports/QBS-2.1.2-linux64-gcc-qt6-5-6-release/sonar_result_folder), it should be possible to find a few files (including build-wrapper.log). Would it be possible for you to share these files with us? I can start a thread with you if you prefer to share the files privately.

When sharing these files, it would be nice if you also have the full tree output from ps -af (especially including the PIDs of each of these processes), and the full terminal output from running the wrapped build command.

A couple of other questions that can help understand the problem:

  1. Does the build process always hang while using build-wrapper? Or is this non-determenistic?
  2. I did a quick test with a small qbs project on my side and I couldn’t reproduce. Do you get this problem on any qbs project, or is this project-specific?
  3. Running the whole tree under strace can help gather some clues why qbs_processlauncher gets stuck. For example, by using strace --output trace.log -ff build-wrapper ....
  4. As a workaround, you can try to generate the compilation database using qbs. For example, by using qbs generate --generator clangdb. See the docs here.

I hope this helps,

Best regards,
Michael

8

Hi Michael,

yes, I’d prefer a more private thread.

The build-wrapper.log is available together with build-wrapper-dump.json and compile_commands.json.

Of course I can provide a new process tree dump by triggering the build again.

Wrt. item 1 and “always hang”: the job containing this SonarCloud PoC is quite new … with out build number 7 we have been able to get everything up and running for the first time using build-wrapper. Now we are at build number 10. All of them have been hanging. But … “always” … hmmm … :wink: … strong word …

Wrt. item 2: this is our PoC project for qbs together with SonarCloud. So … “any qbs project” … hmmm … again a strong term … :wink: …

Wrt. item 3: yes, maybe I could replace qbs_processlauncher by some script containing the corr. strace call. Need to check what/where to change in our build infrastructure …

Wrt. item 4: inside the community here I’ve found a ticket

That one sounds like I run into other trouble with sonar-scanner when trying this. Or has this been fixed within sonar-scanner?

Of course I can also provide proc maps for the qbs_processlauncher process. And the corr. environ file.

And another idea is me writing a question to qbs mailing list asking whether others are using SonarCloud.

9

Hi @HeikoNardmann,

Thank you very much for the information. I am starting a private thread.

10

Unfortunately, The information collected privately didn’t help reproduce the problem described here.

However, based on our testing, the cause seems to be project-specific. Please let me know if you are willing to share the strace logs I requested in the end.

Thanks in advance,
Michael

1 Like
12

Follow this link to read our