AnsweredAssumed Answered

Destructor-calling bug when leaving function due to exception

Question asked by mastermind3001 on Jan 24, 2012
Latest reply on Oct 1, 2013 by Caroll

I have found what appears to me to be a compiler bug.

 

When leaving a function due to an exception having occurred (either in the current function or in some other function that the current function calls), sometimes some of the local variables are not destructed correctly and cause the application to crash. Debugging has shown that, upon entry into a variable's destructor (usually an STL object like string or i/ostringstream), the "this" pointer is wrong. Of course, from there, it's easy to see how a crash may occur.

 

We are working in VisualDSP++ 5.0 Update 10, with C++, with a VDK- and LwIP-enabled project, with exceptions enabled, on a BF518-EZKIT board. An HPUSB-ICE is used for debugging over JTAG. Disassembly before entering a destructor looks like this (usually):

 

R1 = 2 ;

R0 = ROT R# BY 0 ;

CALL __dt__*** ;

 

To get to that code, I put a breakpoint on the local variable's declaration, and the compiler stops there both when it is about to construct the variable and when it is about to destruct it. The problem, when it occurs, is that the register referenced by R# is not the right one. The address of the variable is in a different register. In the current case that I'm looking at, the address is in R4, and the register referenced is R6.

 

This issues appears to maybe be related to the following one:

http://ez.analog.com/message/16205#16205

 

We have modified the default generated LDF file using the user-code sections, and have moved the .gdt, .gdtl, and .frt sections into SDRAM, to leave more space in intermal memory for other things. Our thread stacks, and hence any variables whose destructors fail to get called correctly, live in SDRAM as well (off-chip), because VDK allocates them from the system heap, which lives off-chip, in SDRAM.

 

Please advise. I can't catch exceptions and print them over UART. I have to use breakpoints to look at the exceptions before the application crashes.

Outcomes