Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Serious apparent bug when allocating byte-objects with new[] and constructors

Ian_Mallett1
Beginner
362 Views

Hi,

Here is a simple example:

#include <cstdint>

class Foo final {
    public:
        uint8_t packed;

    public:
        inline Foo(void) : packed(0xFF) {} //causes error
        inline ~Foo(void) = default;
};
static_assert(sizeof(Foo)==sizeof(uint8_t),"Implementation error!");

int main(int /*argc*/, char* /*argv*/[]) {
    Foo* arr = new Foo[4]; //Tried a bunch of different sizes.  All fail.
    delete [] arr;

    return 0;
}

This program is valid C++, yet erroneously corrupts its own memory when run, and crashes. The constructor line appears to be the culprit. The program was compiled with Intel C++ 16.0.

For your convenience, here is a link to a complete solution that demonstrates the problem. Here is a link to the assembled code.

-i

0 Kudos
5 Replies
Melanie_B_Intel
Employee
362 Views

I can reproduce this problem. I opened DPD200408393 in our internal bug tracking database.  Thank you for reporting this.

(The wrong delete operator is being called, if you remove the explicit call to delete the main program will terminate normally.)

 --Melanie

0 Kudos
Melanie_B_Intel
Employee
362 Views

More information on this problem:

This only happens with

inline ~Foo(void) = default;

If you remove “default”, things are okay.

Thanks again for the bug report. --Melanie

0 Kudos
Ian_Mallett1
Beginner
362 Views

N.B., removing the constructor also fixes it. The constructor/destructor use case is just for testing, so I'm not desperate for a workaround. But . . . this is still a pretty serious bug. I will be glad when it is fixed.
Best,

0 Kudos
Ian_Mallett1
Beginner
362 Views

Now we're seeing this bug everywhere. Not to be pushy, but . . . will this be fixed soon, I hope?

There seems to be a related problem where the correct overload of `new` is called, but the value ultimately stored into the pointer is different from the one returned. So e.g. the "ptr" in "Foo* ptr=new Foo[6];" is different from value returned by the "new[]" overload. I stepped through the assembly, but didn't really understand what was going on. It seemed to happen during something like Foo::'vector constructor'. I don't really have time to isolate it, but again, I think this is a related problem.

--Ian

0 Kudos
Anoop_M_Intel
Employee
362 Views

Hi Ian,

This issue is fixed internally and the fix will be available in public domain in our next v16.0 update.

Thanks and Regards
Anoop

0 Kudos
Reply