com.sonar.cpp.analyzer.Analyzer$AnalyzerException: Exit code != 0

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)

    • SonarQube Version 8.6.1 (build 40680), Developer Edition
  • what are you trying to achieve
    I am trying to scan a bigger C++ project with build-wrapper

  • what have you tried so far to achieve this

call "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" amd64
cmake ...
build-wrapper-win-x86-64.exe --out-dir build_wrapper_output_directory msbuild project.sln /m:4 /nr:false /t:proj:Rebuild /p:Configuration="Release" /p:Platform="x64"

After these commands I am scanning the project with sonar-scanner.bat. During that scan I get this error message:

ERROR: Exception in thread pool-3-thread-1
com.sonar.cpp.analyzer.Analyzer$AnalyzerException: Exit code != 0: C:\path\to\file.cpp
	at com.sonar.cpp.analyzer.Subprocess.execute(
	at com.sonar.cpp.analyzer.Subprocess.execute(
	at com.sonar.cpp.plugin.CFamilySensor.lambda$process$8(
	at com.sonar.cpp.analyzer.AnalysisExecutor.lambda$submit$0(
	at java.util.concurrent.Executors$ Source)
	at Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$ Source)
	at Source)

An error occurred while analyzing the following compilation unit: 
A file named "" has been generated to help the problem investigation.
Please contact SonarSource support providing the following file to help improving the analyzer:

Hello ,

On the messages you post, we can see the path C:\path\to\file.cpp. It is not clear to me if this strange path was really written in the displayed message, of if you replaced the original path by this one before publishing, in order to hide some internal data. Could you please clarify?

Assuming this is the second case, to investigate this issue, we would need the file that is mentioned in the message, as well as the analysis log. I’m sending you a private message if you’re willing to share it privately with us.

Hi @JolyLoic thank you for your answer. I replaced the original path to the file with C:\path\to\file.cpp to hide internal data.


Thank to the reproducer you provided us, I’ve been able to reproduce the issue on my side. This is a know issue (see CPP-2696) related to the fact we are using clang to analyze the code, and clang does not play well with boost on Windows. You can see in one of the boost headers:

  template <typename Executor>
  friend BOOST_ASIO_CONSTEXPR blocking_t query(
      const Executor& ex, convertible_from_blocking_t,
      typename enable_if<
        can_query<const Executor&, possibly_t>::value
      >::type* = 0)
#if !defined(__clang__) // Clang crashes if noexcept is used here.
#if defined(BOOST_ASIO_MSVC) // Visual C++ wants the type to be qualified.
      is_nothrow_query<const Executor&, blocking_t<>::possibly_t>::value))
#else // defined(BOOST_ASIO_MSVC)
      is_nothrow_query<const Executor&, possibly_t>::value))
#endif // defined(BOOST_ASIO_MSVC)
#endif // !defined(__clang__)
    return boost::asio::query(ex, possibly_t());

Notice the comment // Clang crashes if noexcept is used here.… This is exactly where the analysis crashes in the reproducer.

The good news it that there is a workaround. If you add -DBOOST_ASIO_DISABLE_NOEXCEPT to your build, the analysis no longer crashes.

I hope this helps!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.