LLVM runs out of memory during Sonar analysis on boost include

Dear community,

I have noticed, that sonar processing fails on some of the files in my project.
To be more precise:

  1. The LLVM component used by sonar, runs out of memory (~500GB) and fails
  2. This failure happens very-very slowly.
  3. Once there is even one failure like this, processing of the project stops, no further files are checked.

LLVM ERROR: out of memory
13:40:21.128 INFO: Requesting reproducer for: REMOVED/config2.cpp
LLVM ERROR: out of memory
14:56:01.430 ERROR: Exception in thread pool-3-thread-1
com.sonar.cpp.analyzer.Analyzer$AnalyzerException: Exit code != 0: REMOVED/config2.cpp
at com.sonar.cpp.analyzer.Subprocess.execute(Subprocess.java:81)
at com.sonar.cpp.analyzer.Subprocess.execute(Subprocess.java:78)
at com.sonar.cpp.plugin.CFamilySensor.lambda$process$7(CFamilySensor.java:556)
at com.sonar.cpp.analyzer.AnalysisExecutor.lambda$submit$0(AnalysisExecutor.java:53)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

Version information:

  • INFO: SonarScanner 4.6.2.2472
  • INFO: Java 11.0.11 AdoptOpenJDK (64-bit)
  • INFO: Linux 3.10.0-1160.11.1.el7.x86_64 amd64
  • Boost version: 1.69.0

I have attached the reproducer file (after removing some parts of paths for security reasons).
Please note, that “#include <boost/algorithm/string.hpp>” in Config2.cpp is the code part triggering the issue. If it is present I get above out of memory error, if I remove it the analysis succeeds.
(It could happen that not even the constructor and destructor are needed, this was the state where all business logical was already removed, I could reproduce the issue in a stable manner, and it took only commenting and uncommenting 1 include to make it pass/fail)

redacted_config2_sonar-cfamily.zip (1008.3 KB)

Hello @Kristof_Szabados,

Welcome to the community!

The reproducer is a binary file and if you modify it we will not be able to reproduce the issue. You can share the original copy privately if you want.
That is that we recently fixed a similar issue and it is going to be part of the next release(should be 2-3 weeks depending on if you are using SonarQube or SonarCloud).

Until then you can exclude that file from the analysis.

Thanks,

Thank you Abbas for the fast reply,

Luckily, the code is not too long.
The header file involved (Config2.hpp)

#ifndef __RO_BASE_CONFIG2_H
#define __RO_BASE_CONFIG2_H

namespace ro
{
namespace base
{

class Config2 final
{
public:
  Config2();
  ~Config2();


};

} // namespace base
} // namespace ro

#endif

And the Config2.cpp contents

// module header file include
#include "base/config/config2.hpp"
#include <boost/algorithm/string.hpp>

namespace ro
{
namespace base
{

/**
 * Default constructor.
 */
Config2::Config2()
{
}

/**
 * Destructor.
 */
Config2::~Config2()
{
}

} // namespace base
} // namespace to

In this case, I was able to rewrite all code parts using that include, so now Sonar can check these files too in my codebase.
I hope by also reporting this limitation I can help the community make Sonar better.

I’m also interested to learn which parts of the boost library make sonar run out of memory and why.

Thank you,
Kristof

Please, if you need some more information, do not hesitate to come back to me.

Hi @Kristof_Szabados,

  • Did you try to define BOOST_NO_CXX14_CONSTEXPR as macro through your build command, and re-run build-wrapper and the scanner? this way you can verify that it is the same issue of the already fixed ticket.

  • If the workaround doesn’t fix the issue, can you share the .reproducer of the simplified example without modifying it?

  • Are you using SonarQube(if yes which version?) or SonarCloud?

Thanks,

Hi @Abbas,

Yes you are right, it looks like adding BOOST_NO_CXX14_CONSTEXPR to the definitions solves the problem.
I’m using SonarQube, so this should be fixed in a few weeks, if I understand you correctly.

Thank you,
Kristof

Hi @Abbas,

I forgot to ask how we can send you the reproducer file privately?
(and what level of private -ness does this mean)

This might be useful in the future.
(for now I have not noticed such an option on this thread, or when uploading a new file)

Thank you in advance,
Kristof

@Kristof_Szabados,

When needed I can start a private thread where you can upload the reproducer.

(and what level of private -ness does this mean)

It means, that the one who sent you the message(in this case myself) will be the only one having access to the file. We(CFamily analyzer maintainers) will use it to recreate the scenario that caused the bug to be able understand it and fix it.

Hope that clarifies!

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