Question

classA objA (0, NULL);
classA & objB (objA);

Assuming the above to be global, can it result in a memory leak? Reasons?

Actually through Valgrind, I am getting an error:

5 bytes in 1 blocks are still reachable
...
global constructors keyed to classA

What does that indicate?

UPDATE:

The exact errors are here.

at 0x4C2659D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6653==    by 0x4EA7BB7: newterminal (in /usr/lib64/R/lib/libR.so)
==6653==    by 0x4EA7D4E: Rf_InitConnections (in /usr/lib64/R/lib/libR.so)
==6653==    by 0x4F420DD: setup_Rmainloop (in /usr/lib64/R/lib/libR.so)
==6653==    by 0x4FEC76A: Rf_initEmbeddedR (in /usr/lib64/R/lib/libR.so)
==6653==    by 0x5C3A8DB: RInside::initialize(int, char const* const*, bool) (in /usr/lib64/R/library/RInside/lib/libRInside.so)
==6653==    by 0x5C3AF60: RInside::RInside(int, char const* const*, bool) (in /usr/lib64/R/library/RInside/lib/libRInside.so)
==6653==    by 0x40D105: global constructors keyed to R

Answer 1

No you never called new so you dont have to call delete.

You should call delete only for dynamically allocated objects. Your object is not dynamically allocated, So you don’t need to. If you do so it will result in Undefined Behavior.

Ofcourse, It is obvious and rather natural to assume that you do not have a class A constructor which leaks memory or causes undefined behavior.

---

Also, note that what is considered as memory leak is open for interpretation.

In your case the object in question is global and it is guaranteed to live throughout the lifetime of your program. Even if this object leaks memory it is a not important at all.
This object is scheduled to be alive till the end of your program and even if it leaked memory, the duration of memory leak is destruction of this global object to the last statement in your program, after which the leaked memory will be reclaimed by the OS once your program ends.

So, practically it does not matter whether this object leaks, ofcourse valgrind would report it as a leak but it leaks when it doesn’t matter to your program.

The kinds of leaks you should be worried about are recurring leaks, functions or constructs which will leak memory repeatedly over the lifetime of the program. This is at best a finite leak scenario and it does not matter.