Problem with CodeWarrior 6.4 and C++ (new/delete)

[stefankaiser]

Hi all,

I am working with CW6.4 on MCF5484 with code written in C for years. I now have to integrate new functionality written in C++ that uses new/delete. Because I have to use dynamic memory management of the RTOS, I wrote 'operator new', 'operator new[]', 'operator delete' and 'operator delete[]' that call the appropriate functions of the RTOS. Single stepping shows that this works correctly.

The problem is, that the compiler generates different code. In some methods 'operator delete[]' is called with the pointer returned by 'operator new[]' and in other methods 8 is subtracted from the pointer before 'operator delete[]' is called (leads to an exception).

Has anyone an idea what I've made wrong or could it be a compiler bug?

Thanks in advance.

Stefan

[trytohelp]

Hi Stefan,

Very sorry for the delay.

this is just to know if the problem/question has been solved or not.

If you've contacted support team with a Service Request number, please provide us the number ?

Regards

Pascal

[stefankaiser]

Hello Pascal,

thank you for your reply.

Unfortunately, the problem has not been solved.

I’ve sent you an email at the end of July under “our old” SR# 1-686268577 addressing the same problem.

Best regards,

by order of Stefan Kaiser

Embedded Systems

Jetter AG

Gräterstraße 2

D-71642 Ludwigsburg

tel. +49 7141 2550-441

fax. +49 7141 2550-425

mailto:skaiser@jetter.de

http://www.jetter.de/

VAT Reg. - No.: DE 812 643 615

Registered: Stuttgart HRB 205545

CEO: Martin Jetter

Board of Directors: Christian Benz, Günter Eckert

Chairman of the Supervisory Board: Dr. Michael Oltmanns

Subscribe now to our internet newsletter at:

http://www.jetter.de/820.0.html

Von: Pascal Irrle

Gesendet: Dienstag, 6. August 2013 10:08

An: Kaiser, Stefan

Betreff: Re: - Problem with CodeWarrior 6.4 and C++ (new/delete)

<https://community.freescale.com/>

Problem with CodeWarrior 6.4 and C++ (new/delete)

reply from Pascal Irrle<https://community.freescale.com/people/trytohelp?et=watches.email.thread> in Classic/Legacy CodeWarrior - View the full discussion<https://community.freescale.com/message/343437?et=watches.email.thread#343437>

[trytohelp]

Hello Stefan,

The SR 1-686268577 is an old one and was for Importer tool.

Under your account I found the SR: 1-1129289327 (library question) which has been investigated by a colleague.

The Status of this SR is Customer Reply Period.

Regarding the New/Delete function.

Coldfire V6.4 is an old version released in April 2007.

I've checked the release note and bug base, but I don't find any entry for a problem linked to new/delete features.

ColdFire V6.4 used the MSL libraries.

EWL libraries were introduced in V7.1.

The MSL libraries are supporting new/delete operators.

If you think there is a problem, please provide us an example showing the behavior ?

Regards

Pascal

[stefankaiser]

Hi Pascal,

thank you for your reply.

I’ll give you a complete overview.

I inherited some CW for ColdFire projects from a colleague who left Jetter few years ago. He started with v6.4 and tried to switch to v7.2.1, but found that the new compiler was buggy. We set back to v6.4 but used the v7.2.1 C lib (EWL) as a subproject, because of the much better performance (especially of the string part). That works fine in different projects for years.

I now have to integrate code from another company written in C+. So I added the source code of the C+ lib of v7.2.1 as a subproject, too. But I got problems with “delete []” (new/new[]/delete/delete[] are widely-used in the new code). In some parts the compiler seems to generate wrong code. The following examples are copies of the debugger window in “Mixed Mode”.

Used macro:

#define SafeDeleteArray(p) {if (EC_NULL!=(p)) {delete [] (p); (p) = EC_NULL;}}

Example for correct compilation: pData is a pointer to ‘unsigned char’.

if (pData != EC_NULL)

40165032: 206EFFA0 movea.l -96(a6),a0

40165036: 4A88 tst.l a0

40165038: 670A beq.s CEcConfigXpat::CfgCreateECatMbxCoeCmd+0x184 (0x40165044); 0x40165044

{

SafeDeleteArray(pData);

4016503A: 4A88 tst.l a0

4016503C: 6706 beq.s CEcConfigXpat::CfgCreateECatMbxCoeCmd+0x184 (0x40165044); 0x40165044

4016503E: 4EB94011EAB0 jsr operator delete[] (0x4011eab0); 0x4011eab0

}

Example for incorrect compilation: pMasterDesc is a pointer to ‘struct’.

if( pMasterDesc != EC_NULL )

401749EC: 4A8C tst.l a4

401749EE: 6712 beq.s CEcDeviceFactory::DeviceFactoryCreateMaster+0x162 (0x40174a02); 0x40174a02

{

SafeDeleteArray(pMasterDesc);

401749F0: 4A8C tst.l a4

401749F2: 670E beq.s CEcDeviceFactory::DeviceFactoryCreateMaster+0x162 (0x40174a02); 0x40174a02

401749F4: 4A8C tst.l a4

401749F6: 670A beq.s CEcDeviceFactory::DeviceFactoryCreateMaster+0x162 (0x40174a02); 0x40174a02

401749F8: 41ECFFF8 lea -8(a4),a0

401749FC: 4EB94011EAB0 jsr operator delete[] (0x4011eab0); 0x4011eab0

}

There’s no source for the commands at addresses 401749f4/401749f6/401749f8. Minus 8 at address 401749f8 leads to an exception. It doesn’t matter if ‘operator delete[]’ calls ‘free’ of the C lib or ‘free’ of our RTOS.

If you will confirm that this is a compiler problem of v6.4 and v10.x compiler does not have such problems, we have to move to v10.x. Ok, then we’ll get problems with the project’s schedule, but there might be no other solution.

Best regards,

by order of Stefan Kaiser

Embedded Systems

Jetter AG

Gräterstraße 2

D-71642 Ludwigsburg

tel. +49 7141 2550-441

fax. +49 7141 2550-425

mailto:skaiser@jetter.de

http://www.jetter.de/

VAT Reg. - No.: DE 812 643 615

Registered: Stuttgart HRB 205545

CEO: Martin Jetter

Board of Directors: Christian Benz, Günter Eckert

Chairman of the Supervisory Board: Dr. Michael Oltmanns

Subscribe now to our internet newsletter at:

http://www.jetter.de/820.0.html

Von: Pascal Irrle

Gesendet: Dienstag, 6. August 2013 14:36

An: Kaiser, Stefan

Betreff: Re: - Problem with CodeWarrior 6.4 and C++ (new/delete)

<https://community.freescale.com/>

Problem with CodeWarrior 6.4 and C++ (new/delete)

reply from Pascal Irrle<https://community.freescale.com/people/trytohelp?et=watches.email.thread> in Classic/Legacy CodeWarrior - View the full discussion<https://community.freescale.com/message/343472?et=watches.email.thread#343472>

[trytohelp]

Hi Stefan,

So you're using CW for Coldfire V6.4 with V7.2 library.

If there is a problem with the compiler, I don't think it's linked to New/delete feature.

this is may be more pointer access.

do you have a short example showing the behavior which I can check on my side ?

Regards

Pascal

[stefankaiser]

Hello Pascal,

I’ve extracted a short example from the megabytes of C++ source code we’ve got. Please find attached the source file “TestFactory.cpp” and the corresponding debugger’s memory window in mixed mode “TestCreate_Mixed.txt”. At address 4000015E you can see that the returned pointer from “operator delete []” is stored in register a4. “operator delete []” is called with a4-8 (address 4000019A). The three commands at addresses 40000192 – 40000196 are only compiled in, if structure “TTestMDesc” contains a member of type “TETHERNET_ADDRESS”.

Regards,

Stefan

Von: Pascal Irrle

Gesendet: Mittwoch, 7. August 2013 15:53

An: Kaiser, Stefan

Betreff: Re: - Problem with CodeWarrior 6.4 and C++ (new/delete)

<https://community.freescale.com/>

Problem with CodeWarrior 6.4 and C++ (new/delete)

reply from Pascal Irrle<https://community.freescale.com/people/trytohelp?et=watches.email.thread> in Classic/Legacy CodeWarrior - View the full discussion<https://community.freescale.com/message/343710?et=watches.email.thread#343710>

[trytohelp]

Hi Stefan,

I've performed some tests with MCU V10.4.

to check it I've created a project from Project wizard for MCF54418.

The hardware used is TWR-MCF5441X with OSJTAG interface.

due to memory issue I changed the value of

      unsigned int  dwSize  = 1024;

by  unsigned int dwSize = 10;

I've reproduced the problem when DestMacAddr is defined as ETHERNET_ADDRESS type.

when DestMacAddr is defined as unsigned short, the example is running fine.

to check the example I called in a main function:

      poTestClass->TestCreate(1);

      test->TestCreate(2);

for ETHERNET_ADDRESS type, the pTestMDesc is defined at

      0x8000f420 for poTestClass->TestCreate(1);

      0x8000f438 for test->TestCreate(2);

            As delete function is called we should expect to have the same address used

for unsigned short tape, the pTestMDesc is defined at

      0x8000f420 for poTestClass->TestCreate(1);

      0x8000f420for test->TestCreate(2);

If I'm right, this is the problem you've on your side too.

Let me know if I'm wrong.

I will contact the compiler team to get their feedback.

Keep you informed.

Regards

Pascal

[stefankaiser]

Hello Pascal,

yes, operator delete/[] should always be called with the address returned by operator new/[], independently of the contents of this memory part.

Regards,

Stefan

Von: Pascal Irrle

Gesendet: Dienstag, 20. August 2013 14:50

An: Kaiser, Stefan

Betreff: Re: - Problem with CodeWarrior 6.4 and C++ (new/delete)

<https://community.freescale.com/>

Problem with CodeWarrior 6.4 and C++ (new/delete)

reply from Pascal Irrle<https://community.freescale.com/people/trytohelp?et=watches.email.thread> in Classic/Legacy CodeWarrior - View the full discussion<https://community.freescale.com/message/345680?et=watches.email.thread#345680>

[trytohelp]

Hi Stefan,

I got feedback from compiler team regarding this problem.

Following their recommendation I tried on my side with MCU V10.4 (EWL lib) and Coldfire V6.4 (MSL lib).

Now the delete function is running fine.

their comments:

++++++++++++++

If he wants to allocate a pointer to one element of type TTestMDesc , the use of new should be:

pTestMDesc = new (structTTestMDesc)

and the delete:

delete(p)

If he wants to allocate a pointer to an array:

pTestMDesc = new struct TTestMDesc[10]; 

and the corresponding delete:

delete[](p)

++++++++++++++

Under your example code, I've changed the SafeDeleteArray macro to:

#define    SafeDeleteArray(p)  {if (0!=(p)) {delete (p); (p) = 0;}}

Attached you will find an example project based on your example.

this is running with V6.4 with MSL lib under simulator.

regards

Pascal

[stefankaiser]

Hi Pascal,

omitting the square brackets in macro SafeDeleteArray is not an option. As I stated in one of my previous emails this example is an extraction from code of another company which is running on a lot of different targets. In the original code SafeDeleteArray is used with different types. In this simple example it might be possible to use only delete (without []), but not as a general solution.

According to the comments from the compiler team I’ve changed new/delete[] in TestClass::TestCreate for test purposes to:

pTestMDesc = new struct TTestMDesc ;

and

delete[] pTestMDesc;

With this, the compiler adds a call to __construct_new_array() after allocating memory. This function adds 8 to the pointer returned by operator new[]. So, subtracting 8 from pTestMDesc before calling operator delete [] is ok.

But it must not subtract 8, if it hasn’t called __construct_new_array() before.

Because it isn’t our code, we can’t change it. (And why should they change it? It works fine with other compilers).

Any help appreciated …

Regards,

Stefan

Von: Pascal Irrle

Gesendet: Donnerstag, 22. August 2013 11:48

An: Kaiser, Stefan

Betreff: Re: - Re: Problem with CodeWarrior 6.4 and C++ (new/delete)

<https://community.freescale.com/>

Re: Problem with CodeWarrior 6.4 and C++ (new/delete)

reply from Pascal Irrle<https://community.freescale.com/people/trytohelp?et=watches.email.thread> in Classic/Legacy CodeWarrior - View the full discussion<https://community.freescale.com/message/346077?et=watches.email.thread#346077>

[trytohelp]

Hi Stefan,

So it's not possible to change the SafeDeleteArray(p) macro.

The macro must be:

      #define SafeDeleteArray(p) {if(0!=(p)) {delete[] (p); (p) = 0;}}

I've tried the development proposal but it's not working.

I will contact them and will keep you informed.

Regards

Pascal

[trytohelp]

Stefan,

I got feedback from compiler team.

they've corrected the example project I sent and I tested it under V6.4 and MCU V10.4.

See below their feedback:

+++++++++++++++++

I’ve done some changes on your code.

The problem was that you didn’t change the allocation of    pTestMDesc = (PTestMDesc)new(unsigned char[dwSize]);

but the allocation of poTestClass = new struct TestClass[10];

+++++++++++++++++

Attached you will find the example running under V6.4.

Please have a look to the main_1.c.

Regards

Pascal

[stefankaiser]

Hello Pascal,

I actually know that I didn’t change the allocation of pTestMDesc, because I can’t change it. Please read my last email.

Best regards,

Stefan

Von: Pascal Irrle

Gesendet: Dienstag, 27. August 2013 17:56

An: Kaiser, Stefan

Betreff: Re: - Re: Re: Problem with CodeWarrior 6.4 and C++ (new/delete)

<https://community.freescale.com/>

Re: Re: Problem with CodeWarrior 6.4 and C++ (new/delete)

reply from Pascal Irrle<https://community.freescale.com/people/trytohelp?et=watches.email.thread> in Classic/Legacy CodeWarrior - View the full discussion<https://community.freescale.com/message/346952?et=watches.email.thread#346952>

[trytohelp]

Hi Stefan,

the last attachment I sent included 2 tagets:

      - V2_ISS Console Debug which uses the process proposed by compiler team solving the problem,

      - test which is based on your code.

does the code used by test target (main.c) is working with another build tool chain (compiler) ?

      which one ?

for our compiler team, there is a problem with this code.

Regards

Pascal

[stefankaiser]

Hi Pascal,

target “V2_ISS Console Debug” calls __contruct_new_array() after allocating the memory. Then it is correct to subtract 8 from the pointer before calling the memory release function.

Target “test” does not call __contruct_new_array() after allocating the memory. Then it is not correct to subtract 8 from the pointer before calling the memory release function.

Additionally, it depends on the structure TETHERNET_ADDRESS. For target “test” the compiler subtracts 8 only, if this structure contains the overloading of operators. With only the simple 6 bytes array, it works fine.

The supplier of the original code told me, that they’ve checked the pairing of new/delete and new[]/delete[] with “Valgrind” and got now errors. It is running on different targets, compiled with different tool chains.

For example: Linux on PPC with GCC from Freescale, RTOS-32 on x86 with VisualStudio from Microsoft.

Regards,

Stefan

Von: Pascal Irrle

Gesendet: Mittwoch, 28. August 2013 10:48

An: Kaiser, Stefan

Betreff: Re: - Problem with CodeWarrior 6.4 and C++ (new/delete)

<https://community.freescale.com/>

Problem with CodeWarrior 6.4 and C++ (new/delete)

reply from Pascal Irrle<https://community.freescale.com/people/trytohelp?et=watches.email.thread> in Classic/Legacy CodeWarrior - View the full discussion<https://community.freescale.com/message/347119?et=watches.email.thread#347119>

[trytohelp]

Hi Stefan,

To continue our investigation I've created a SR for this question.

This is 1-1150597658.

I will keep you informed.

Pascal

[trytohelp]

Hi,

If I'm right, you're using Coldfire V6.4 development tool with the V7.2 EWL lib instead of  MSL lib.

Under V6.4, I've created a project for MCF54xx ISS (simulation).

I've added your source file in the project and disassemled the file for:

      - case A: your default file,

      - case B: with //ETHERNET_ADDRESS    DestMacAddr;

I think I got similar code

Case A:

;   80:         SafeDeleteArray(pTestMDesc);

;   81:     }

;   82: 

;

0x00000056  0x4A8C                   tst.l    a4

0x00000058  0x6710                   beq.s    *+18                  ; 0x0000006a

0x0000005A  0x4A8C                   tst.l    a4

0x0000005C  0x670C                   beq.s    *+14                  ; 0x0000006a

0x0000005E  0x41ECFFF8               lea      -8(a4),a0

0x00000062  0x2E88                   move.l   a0,(a7)

0x00000064  0x4EB900000000           jsr      ___dla__FPv

Case B:

;   80:         SafeDeleteArray(pTestMDesc);

;   81:     }

;   82: 

;

0x00000052  0x4A8C                   tst.l    a4

0x00000054  0x6708                   beq.s    *+10                  ; 0x0000005e

0x00000056  0x2E8C                   move.l   a4,(a7)

0x00000058  0x4EB900000000           jsr      ___dla__FPv

I used the MSL lib for my tests.     

I will check with MCU V10.x tool chain.

Keep you informed.

Regards

Pascal

[trytohelp]

Hi Stefan,

Sorry for the delay, I was in vacation last week.

I will check the example sent and will keep you informed.

I plan to check it this afternoon or tomorow.

Regards

Pascal