Ugly exception handling bug in 11.1.5

[AlexBelo 12]

Hi all.

I'm on CB2007 for many years. After last special BCB "quality release" I've eventually decided to try a modern version.

void __fastcall TfrmMain::btnHelloClick(TObject *Sender)
{
 ShowMessage(L"Hello, World!");
 for(int i=0; i<10000000; ++i, ++t)
 {
  try {
   try { throw Exception(L"Message Message Message Message Message Message Message Message Message Message Message "); }
   catch(const Exception& e) { throw; }
  } catch(const Exception& e) { }
 }

 ShowMessage(L"Good bye, World!");
}

CLANG compiler, static linkage.

 

Memory Initial     Final          (data from Task Manager)

Win64    17680K  18328K      Some leak?..

Win32     5080K   1734332K  !!!!!!!!!!!!!!!!!!

 

madExcept reports memory leak on every rethrowing in catch (tested without loop, of course) in Win32.

Unfortunately I can't test it in details in Win64 version (because it looks like madExcept still doesn't support bcb64) but subtle hint on memory leak is also visible in test results.

 

Before posting QP report I would like to see your comments/results.

[Der schöne Günther 316]

I stopped using C++ Builder because of the truly abysmal exception handling with Clang. The leaks were the least of my concern.

 

According to [RSP-13173] C++ compiler exception handling is completely broken - Embarcadero Technologies, it should have been fixed, and they even had a blog post how it should have been improved with 10.4.2:

Quote

This means that in 10.4.2 you should see significantly improved exception handling behavior and a large number of quality issues resolved for in-module exceptions, cross-module exceptions, where modules are all statically or all dynamically linked, for OS, C++ and SEH exceptions, and across both Win32 and Win64 – a massive test matrix.

(Source)

 

Sad to see it's still not properly fixed. They have been having the LLVM backend for C++ for what now... ten years?

Edited July 22, 2022 by Der schöne Günther

[AlexBelo 12]

Testing your cases in last version, Win32 build:

 

ACCESS VIOLATION DURING STACK UNWIND

No AV but a lot of memory leaks.

 

Not Firing Destructors When It Should

Destructors are on place but memory leaks.

 

TRY/CATCH LEAK

This very basic case is really fixed.

 

Fire Destructors Twice

No double destruction but memory leaks.

 

AFAIUI all memory leaks are unproperly handled exception objects.

Edited July 22, 2022 by AlexBelo

[AlexBelo 12]

https://quality.embarcadero.com/browse/RSP-38717?jql=