Error occured while analyzing compilation unit

C++ 17 project using gcc, clang-tidy and clang-format next to sonarCloud.
In the following example the sonar cpp analyzer crashes.
It crashes due to a virtual function call that’s accessed through the inherited class, example below.

This only became an issue once we moved the ok() implementation to the baseClass instead of having it pure virtual with implementation in the derived classes.

We can privately share the sonar-cfamily-reproducer.tar.xz

For now we avert the crash by using the casting method, though this should be avoided.

The following may not compile, it is just an illustration:

finalInterface.cpp:

#include "finalInterface.h"
#include "interfaces.h"
#include "interfaceOne.h"
#include "interfaceTwo.h"
void FinalInterface::someFunction() {
// This crashes sonar analysis,
// We require both functions to be called
IFaceOne::ok();
IFaceTwo::ok();
// This does not crash sonar analysis:
dynamic_cast<IFaceOne*>(this)->ok()
dynamic_cast<IFaceTwo*>(this)->ok()
}

interfaces.h:

class IFace {
public:
virtual void ok()
{
// virtual because a specialized vector interface exists
// ok
}
};

interfaceOne.h:

#include "interfaces.h"
class IFaceOne: public IFace {
// this does not override ok
};

interfaceTwo.h:

#include "interfaces.h"
class IFaceTwo: public IFace {
// this does not override ok
};

finalInterface.h:

#include "interfaces.h"
#include "interfaceOne.h"
#include "interfaceTwo.h"
class FinalInterface: public IFaceOne, public IFaceTwo
{
public:
void someFunction();
};

Hi @xemex, thank you for reaching out.
I’ll PM you and take it from there. Thank you!

Thank you for your report. It was really valuable. In the end your sample uncovered 3 different crashes in our analyzer: CPP-6631, CPP-6632, CPP-6633
This is why it took so long for me to come back to you.

This should side step the crash, yes. Although, I agree that this is not an ideal solution just to satisfy our analyzer. Alternatively, you can exclude the affected file(s) from the analysis, but I’d rather recommend a more refined approach:

You can disable the S1699 rule to avoid the crash within that rule implementation, but you would still have a crash in the symbolic-execution part. I could also share the option to disable the symbolic-execution stage on the affected file(s) to mitigate that crash.
This would mean a slightly degraded analysis quality, but you would not need to use the dynamic_cast. Let me know if this helped.

Hi, yeah instead we opted to exclude the file from sonar analysis.

Good it was of help. Can I request you to remove the provided sonar-cfamily-reproducer.tar.xz file from your system?

Thank you!

I’ve removed all traces and from our private tracker.

1 Like

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