0

Project based on COM technology. I have logged error by JCL on Delphi XE4 64Bit (SKGeneral64 is COM Dll):

ERR (ThreadID=14C8 14.02.2014 16:43:14:274) - Exception class: _TExitDllException
Exception address: 000000000536DBAE
Stack list, generated 14.02.2014 16:43:14
[000000000536DBAE] System.ExitDll + $3E
[000000000536DCF4] System.@Halt0 + $54
[000000000536D5E3] System.@StartLib + $123
[0000000005375FA2] SysInit.@InitLib + $92
[00000000056D7938] SKGeneral64.SKGeneral64 + $38
[000000007777C76C] Unknown function at RtlUserThreadStart + $26C
[000000007777C42F] Unknown function at LdrInitializeThunk + $10F
[000000007777C32E] LdrInitializeThunk + $E
----------------------------------------------------------------------------------------------------
System   : Windows 7 Professional, Version: 6.1, Build: 1DB1, "Service Pack 1"
Processor: Intel, Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz, 2960 MHz MMX
----------------------------------------------------------------------------------------------------
Module: C:\PROGRA~2\SKBKON~1\Active\Bin\SKGENE~2.DLL   Modified: 14.02.2014 16:42:37
Version: 1.0.0.0  Description: 

What the reason of it? Could it be the cause of the memory leaks and memory fragmentation?

Sibay
  • 119
  • 1
  • 9

1 Answers1

3

Having done a bit of digging around, it seems that this exception is expected and is the way that a thread returns its exit code when the thread terminates.

Here's how it goes. A call is made to System.ExitDll which does this:

procedure ExitDll(Context: PInitContext);
var
  ResultExitCode: Integer;
begin
  Context^ := Context.OuterContext^;
  ResultExitCode := ExitCode;
  ExitCode := 0;
  //raise _TExitDllException.Create(ResultExitCode);
  _RaiseExcept(_TExitDllException.Create(ResultExitCode));
end;

That's what raises the exception. The exception is handled in _HandleExitDllException:

function _HandleExitDllException: Integer;
var
  ExceptionObject: TObject;
begin
  Result := -1;
  ExceptionObject := ExceptObject;
  if ExceptionObject is _TExitDllException then
    Result := _TExitDllException(ExceptionObject).ExitCode
  else
    _UnhandledException;
  _DoneExcept;
end;

This code read the exit code from the exception and returns that value to the caller. You can't see any code in the RTL that calls _HandleExitDllException, presumably because that is linked in magically by the compiler/linker.

Essentially this is a false positive from your error reporting software. This exception is part of normal program execution. There is nothing to worry about. Apart from your error reporting code which seems to deficient.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Can it be memory leak like this? [link](http://stackoverflow.com/questions/10548888/memory-leak-in-the-win64-delphi-rtl-during-thread-shutdown) – Sibay Feb 14 '14 at 13:20
  • Why do you think it is a leak? My guess is that your bug reporting software is deficient. I'm a fan of madexcept. – David Heffernan Feb 14 '14 at 13:22
  • In the question you ask: *Could it be the cause of the memory leaks and memory fragmentation?* What memory leaks? What fragmentation? – David Heffernan Feb 14 '14 at 13:35
  • I have no reported memory leaks by my application (using FastMM4). But program's memory usage is still growing (about 50-100mb per day). I thougt maybe reason like this [Link to Stackoverflow](http://stackoverflow.com/questions/10548888/memory-leak-in-the-win64-delphi-rtl-during-thread-shutdown) leaks -> fragmentation – Sibay Feb 15 '14 at 09:51
  • How do you measure that? – David Heffernan Feb 15 '14 at 09:56
  • Process explorer/Memory usage feature in FastMM. After the weak application crashes with Out of memory when try to get memory. – Sibay Feb 15 '14 at 10:19
  • Are you constantly creating and destroying threads? Because I believe there is a known leak relating to thread destruction. There's a qc report containing the name of the exception class that is the subject of this Q. – David Heffernan Feb 15 '14 at 11:37
  • Yes, threads are creates constantly, when user connect/disconnect, start/stop working (ADO connections to SQL are on threads too). So if that is known leak, then it can be reason of memory fragmentation? Right, David? – Sibay Feb 15 '14 at 14:21
  • Yes, this is exactly what I reported in 2012 : http://stackoverflow.com/questions/10548888/memory-leak-in-the-win64-delphi-rtl-during-thread-shutdown – Adrien Reboisson Apr 22 '14 at 16:04
  • @AdrienReboisson That was fixed in XE6. I tried it - works great. No more memory fragmentation, no more "Out of memory", no more crashes. – Sibay Jun 17 '14 at 07:44
  • @Sibay Thank you very much for the news, I plan to migrate to XE6 soon ! – Adrien Reboisson Jun 18 '14 at 09:48