Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.



Permlink Replies: 26 - Last Post: Jun 5, 2014 8:45 PM Last Post By: Steve Faleiro
Jaimi McEntire

Posts: 6
Registered: 10/27/99
Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 21, 2010 1:33 PM
There is a serious bug in the VCL that will eat up atoms in the private atom table. Windows has a limited number of private atoms in the private atom table (32767), and this is shared by Windows classes, Windows Messages, Clipboard formats, etc. Every time the controls module is initialized, it creates a new Windows Message:

ControlAtomString := Format('ControlOfs%.8X%.8X', [HInstance, GetCurrentThreadID]);
ControlAtom := GlobalAddAtom(PChar(ControlAtomString));
RM_GetObjectInstance := RegisterWindowMessage(PChar(ControlAtomString));

The problem is multiplied by the number of DLL's that the application contains that includes the controls module. If you have 10 dll's, and one application, this code will consume 11 atoms every time it is ran.

When the system is ran out of atoms in the private atom table, no window class can be registered. This means, no windowed programs will be able to open after the private atom table is full.

These window messages cannot be deleted - there is simply no call to delete them that is exposed (there are calls in win32k.sys, but they cannot be accessed by the application). These atoms are deleted after the user logs out of windows, so this may not affect you. However, if your application is spawning processes, this can take the entire system down.

For my use, I have solved this by modifying controls.pas, including it directly in my c++ builder application, and changing the offending line as follows:

RM_GetObjectInstance := WM_USER+199; // an unused WM_USER message
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 21, 2010 9:50 PM   in response to: Jaimi McEntire in response to: Jaimi McEntire
<Jaimi McEntire> wrote in message news:315622 at forums dot embarcadero dot com...

For my use, I have solved this by modifying controls.pas

Another option would be to recompile the App and DLLs with runtime packages
enabled. That way, there will be a single copy of the Controls unit loaded
and shared amongst them.

--
Remy Lebeau (TeamB)
Jaimi McEntire

Posts: 6
Registered: 10/27/99
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 29, 2010 8:11 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
That might make it less of a problem, but it still consumes atoms until they are exhausted, albeit at a lower rate.

Remy Lebeau (TeamB) wrote:
<Jaimi McEntire> wrote in message news:315622 at forums dot embarcadero dot com...

For my use, I have solved this by modifying controls.pas

Another option would be to recompile the App and DLLs with runtime packages
enabled. That way, there will be a single copy of the Controls unit loaded
and shared amongst them.

--
Remy Lebeau (TeamB)
Luis Branca

Posts: 2
Registered: 1/2/06
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 22, 2010 1:58 AM   in response to: Jaimi McEntire in response to: Jaimi McEntire
Jaimi McEntire wrote:
(...)
The problem is multiplied by the number of DLL's that the application contains that includes the controls module.>

Is this issue exacerbated by "leaking" these private atoms each time the DLL's are loaded?
Let's say a system service that occasionally requires some DLL and must load/unload it.
Will this resource burning just keep escalating? If so it is a pretty serious limitation.
Would you be kind enough to fill in a case on QualityCentral for it? Really appreciated.

Btw, runtime packages enabled may be a short mitigating factor because lots of
applications are intentionaly monolithic (single large EXE - no external dependencies
on launching).
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 22, 2010 2:16 AM   in response to: Luis Branca in response to: Luis Branca
<Luis Branca> wrote in message news:315715 at forums dot embarcadero dot com...

Is this issue exacerbated by "leaking" these private atoms
each time the DLL's are loaded? Let's say a system service
that occasionally requires some DLL and must load/unload it.
Will this resource burning just keep escalating? If so it is a
pretty serious limitation.

I would have to double-check older versions to be sure, but recent versions
do free the atoms when the Controls unit is unloaded.

--
Remy Lebeau (TeamB)
Luis Branca

Posts: 2
Registered: 1/2/06
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 22, 2010 5:52 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
(...)
I would have to double-check older versions to be sure, but recent versions
do free the atoms when the Controls unit is unloaded.

Ok then, if even DLL's compiled with "Dynamic RTL" = false and
"Build with Runtime Packages" = false won't leak the atoms on DLL unloading,
in RS > = 2010, it shouldn't be a too serious issue (for us and atm, at least).

Thanks for checking it, Remy.
Scott Robinet

Posts: 3
Registered: 8/20/07
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 24, 2010 5:47 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
<Luis Branca> wrote in message news:315715 at forums dot embarcadero dot com...

Is this issue exacerbated by "leaking" these private atoms
each time the DLL's are loaded? Let's say a system service
that occasionally requires some DLL and must load/unload it.
Will this resource burning just keep escalating? If so it is a
pretty serious limitation.

I would have to double-check older versions to be sure, but recent versions
do free the atoms when the Controls unit is unloaded.

--
Remy Lebeau (TeamB)

Hi Remy,

This is actually a serious problem for us because we've created several COM objects that several other third-parties use, sometimes excessively. I've been chasing this very issue for months and was ecstatic when Jaimi found the cause and a workaround.

When you say "recent versions", do you mean internal builds? Or at least XE? We're using Builder 2010 with all updates.

Regards,
Scott
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 25, 2010 9:40 PM   in response to: Scott Robinet in response to: Scott Robinet
<Scott Robinet> wrote in message news:316235 at forums dot embarcadero dot com...

When you say "recent versions", do you mean internal builds?

No. I checked the release version of 2010. The finalization section of
Control.pas calls GlobalDeleteAtom() to free the two allocated atoms.
However, Jaimi is right that a unique window message ID is consumed and
leaked with each VCL module that runs. The only place that the VCL uses the
RM_GetObjectInstance message is inside the ObjectFromHWnd() function, which
validates the target HWND belongs to the calling process before issuing the
message, so there is no need for RM_GetObjectInstance to use a registered
message ID that is unique for each running VCL process. A single commonly
shared global name would have worked fine (I would not have relied on using
WM_USER, like Jaimi's workaround does).

--
Remy Lebeau (TeamB)
Scott Robinet

Posts: 3
Registered: 8/20/07
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 26, 2010 7:38 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
A single commonly
shared global name would have worked fine (I would not have relied on using
WM_USER, like Jaimi's workaround does).

In other words, would you suggest changing:
ControlAtomString := Format('ControlOfs%.8X%.8X', [HInstance, GetCurrentThreadID]);
to
ControlAtomString := 'ThisIsAnAtomStringForAllVCLControls'; (for example)

and leaving the assignment of RM_GetObjectInstance as is?
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 26, 2010 6:14 PM   in response to: Scott Robinet in response to: Scott Robinet
<Scott Robinet> wrote in message news:316369 at forums dot embarcadero dot com...

In other words, would you suggest changing:
ControlAtomString := Format('ControlOfs%.8X%.8X', [HInstance,
GetCurrentThreadID]);
to
ControlAtomString := 'ThisIsAnAtomStringForAllVCLControls'; (for example)

and leaving the assignment of RM_GetObjectInstance as is?

No. ControlAtomString needs to be a per-process unique name. That is how
ControlAtom is designed, and that is important for the way TWinControl works
internally. However, I do not believe that the RM_GetObjectInstance message
should use the same name as ControlAtom. It should have its own name, and
that name does not need to unique across processes, eg:

RM_GetObjectInstance := RegisterWindowMessage('RM_GetObjectInstance');


--
Remy Lebeau (TeamB)
Scott Robinet

Posts: 3
Registered: 8/20/07
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 26, 2010 7:04 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Thanks Remy! Very, very much appreciated.
Jaimi McEntire

Posts: 6
Registered: 10/27/99
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 29, 2010 8:14 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
That message consumes an atom from the private atom table. It has no relation to the global atom table. It's an internal atom table that windows uses for window classes, window messages, and clipboard formats.

Jaimi

Remy Lebeau (TeamB) wrote:
<Scott Robinet> wrote in message news:316235 at forums dot embarcadero dot com...

When you say "recent versions", do you mean internal builds?

No. I checked the release version of 2010. The finalization section of
Control.pas calls GlobalDeleteAtom() to free the two allocated atoms.
However, Jaimi is right that a unique window message ID is consumed and
leaked with each VCL module that runs. The only place that the VCL uses the
RM_GetObjectInstance message is inside the ObjectFromHWnd() function, which
validates the target HWND belongs to the calling process before issuing the
message, so there is no need for RM_GetObjectInstance to use a registered
message ID that is unique for each running VCL process. A single commonly
shared global name would have worked fine (I would not have relied on using
WM_USER, like Jaimi's workaround does).

--
Remy Lebeau (TeamB)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 26, 2010 6:38 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
"Remy Lebeau (TeamB)" <no dot spam at no dot spam dot com> wrote in message
news:315720 at forums dot embarcadero dot com...

I would have to double-check older versions to be sure, but
recent versions do free the atoms when the Controls unit is unloaded.

The atoms are freed on finalization in BCB 6, maybe earlier. The
RM_GetObjectInstance message (and the leak) was introduced in BCB 6, though,
so this is a long time leak.

--
Remy Lebeau (TeamB)
Jaimi McEntire

Posts: 6
Registered: 10/27/99
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 29, 2010 8:10 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
No, it doesn't.

There is a second atom created here:

RegisterWindowMessage(PChar(ControlAtomString));

This is not freed, because it cannot be freed - there is no way to do it. It's not a GLOBALATOM, it's in the private atom table, which we do not have access to. This has taken weeks of time, and weeks of Microsoft Premier support time, to find out this issue. It still exists in CBuilder XE.

Jaimi


Remy Lebeau (TeamB) wrote:
<Luis Branca> wrote in message news:315715 at forums dot embarcadero dot com...

Is this issue exacerbated by "leaking" these private atoms
each time the DLL's are loaded? Let's say a system service
that occasionally requires some DLL and must load/unload it.
Will this resource burning just keep escalating? If so it is a
pretty serious limitation.

I would have to double-check older versions to be sure, but recent versions
do free the atoms when the Controls unit is unloaded.

--
Remy Lebeau (TeamB)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2010 9:06 PM   in response to: Jaimi McEntire in response to: Jaimi McEntire
<Jaimi McEntire> wrote in message news:316872 at forums dot embarcadero dot com...

No, it doesn't.

The two explicit atoms - ControlAtom and WindowAtom - are indeed freed, in
all versions from BCB6 onwards. The RM_GetObjectInstance atom is not (and
cannot be) freed, as you noticed. I already reported it to QC:

Report No: 90511 Status: Reported
Resource leak caused by RM_GetObjectInstance message
http://qc.embarcadero.com/wc/qcmain.aspx?d=90511

--
Remy Lebeau (TeamB)
Jaimi McEntire

Posts: 6
Registered: 10/27/99
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 3, 2011 8:23 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Just trying to be explicit about what has changed so people don't get on the wrong track somewhere.
Thanks for reporting this.

Jaimi

Remy Lebeau (TeamB) wrote:
<Jaimi McEntire> wrote in message news:316872 at forums dot embarcadero dot com...

No, it doesn't.

The two explicit atoms - ControlAtom and WindowAtom - are indeed freed, in
all versions from BCB6 onwards. The RM_GetObjectInstance atom is not (and
cannot be) freed, as you noticed. I already reported it to QC:

Report No: 90511 Status: Reported
Resource leak caused by RM_GetObjectInstance message
http://qc.embarcadero.com/wc/qcmain.aspx?d=90511

--
Remy Lebeau (TeamB)
Gregor Brandt

Posts: 108
Registered: 12/9/09
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 22, 2010 5:31 AM   in response to: Jaimi McEntire in response to: Jaimi McEntire
This is in XE as well, or only previous versions?

Jaimi McEntire wrote:
There is a serious bug in the VCL that will eat up atoms in the private atom table. Windows has a limited number of private atoms in the private atom table (32767), and this is shared by Windows classes, Windows Messages, Clipboard formats, etc. Every time the controls module is initialized, it creates a new Windows Message:

ControlAtomString := Format('ControlOfs%.8X%.8X', [HInstance, GetCurrentThreadID]);
ControlAtom := GlobalAddAtom(PChar(ControlAtomString));
RM_GetObjectInstance := RegisterWindowMessage(PChar(ControlAtomString));

The problem is multiplied by the number of DLL's that the application contains that includes the controls module. If you have 10 dll's, and one application, this code will consume 11 atoms every time it is ran.

When the system is ran out of atoms in the private atom table, no window class can be registered. This means, no windowed programs will be able to open after the private atom table is full.

These window messages cannot be deleted - there is simply no call to delete them that is exposed (there are calls in win32k.sys, but they cannot be accessed by the application). These atoms are deleted after the user logs out of windows, so this may not affect you. However, if your application is spawning processes, this can take the entire system down.

For my use, I have solved this by modifying controls.pas, including it directly in my c++ builder application, and changing the offending line as follows:

RM_GetObjectInstance := WM_USER+199; // an unused WM_USER message
Alex Belo

Posts: 626
Registered: 10/8/06
Re: Serious bug in VCL eats up private atoms and makes sytem unstable.Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 26, 2010 1:28 AM   in response to: Gregor Brandt in response to: Gregor Brandt
Gregor Brandt wrote:

This is in XE as well, or only previous versions?

I see the same in RAD2007.
No such code in CB5 sources.
QC 90511 is filed for v.15 (XE).

--
Alex
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable.Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 26, 2010 2:32 AM   in response to: Alex Belo in response to: Alex Belo
"Alex Belo" <b dot a dot v at inbox dot ru> wrote in message
news:316339 at forums dot embarcadero dot com...

QC 90511 is filed for v.15 (XE).

That is because there is no point in filing it for old versions that will
not see any further updates.

--
Remy Lebeau (TeamB)
Alex Belo

Posts: 626
Registered: 10/8/06
Re: Serious bug in VCL eats up private atoms and makes sytemunstable.Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 26, 2010 4:08 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:

That is because there is no point in filing it for old versions that
will not see any further updates.

Yes, I know.
It was only indirect (I have not XE at hand) answer on the first part
of Gregor's question:

This is in XE as well, or only previous versions?

QC 90511 is filed for v.15 (XE).

(hence, "yes, in XE too" :-) )

--
Alex
Jaimi McEntire

Posts: 6
Registered: 10/27/99
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 29, 2010 8:15 AM   in response to: Gregor Brandt in response to: Gregor Brandt
Exists in XE, as well as C2007. I do not know about previous versions.

Gregor Brandt wrote:
This is in XE as well, or only previous versions?

Jaimi McEntire wrote:
There is a serious bug in the VCL that will eat up atoms in the private atom table. Windows has a limited number of private atoms in the private atom table (32767), and this is shared by Windows classes, Windows Messages, Clipboard formats, etc. Every time the controls module is initialized, it creates a new Windows Message:

ControlAtomString := Format('ControlOfs%.8X%.8X', [HInstance, GetCurrentThreadID]);
ControlAtom := GlobalAddAtom(PChar(ControlAtomString));
RM_GetObjectInstance := RegisterWindowMessage(PChar(ControlAtomString));

The problem is multiplied by the number of DLL's that the application contains that includes the controls module. If you have 10 dll's, and one application, this code will consume 11 atoms every time it is ran.

When the system is ran out of atoms in the private atom table, no window class can be registered. This means, no windowed programs will be able to open after the private atom table is full.

These window messages cannot be deleted - there is simply no call to delete them that is exposed (there are calls in win32k.sys, but they cannot be accessed by the application). These atoms are deleted after the user logs out of windows, so this may not affect you. However, if your application is spawning processes, this can take the entire system down.

For my use, I have solved this by modifying controls.pas, including it directly in my c++ builder application, and changing the offending line as follows:

RM_GetObjectInstance := WM_USER+199; // an unused WM_USER message
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 31, 2010 9:07 PM   in response to: Jaimi McEntire in response to: Jaimi McEntire
<Jaimi McEntire> wrote in message news:316878 at forums dot embarcadero dot com...

Exists in XE, as well as C2007. I do not know about previous versions.

The RM_GetObjectInstance message (and hense its atom leak) was introduced in
BCB 6.

--
Remy Lebeau (TeamB)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 25, 2010 9:48 PM   in response to: Jaimi McEntire in response to: Jaimi McEntire
<Jaimi McEntire> wrote in message news:315622 at forums dot embarcadero dot com...

There is a serious bug in the VCL that will eat up atoms in the private
atom table.

I have logged this to QC:

Report No: 90511 Status: Reported
Resource leak caused by RM_GetObjectInstance message
http://qc.embarcadero.com/wc/qcmain.aspx?d=90511

--
Remy Lebeau (TeamB)
Trevor Magnusson

Posts: 2
Registered: 2/24/06
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2011 11:56 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
I have logged this to QC:

Still no action, six months later.

Question: I can edit controls.pas and implement Remy's suggested fix, I can even compile it to controls.dcu. But for projects built with runtime packages, I will need a new vcl140.bpl (I am using RAD Studio 2010).
How does one rebuild vcl140.bpl ???
I have the "professional" install, including source code, but I can't find any .DPK file for vcl140.

Edited by: Delphi Developer on Jun 22, 2011 11:57 PM
Steve Faleiro

Posts: 77
Registered: 3/11/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable. Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 5, 2014 8:14 PM   in response to: Jaimi McEntire in response to: Jaimi McEntire
Thanks for the fix available on EMBT CodeCentral!

--
Steve Faleiro

Jaimi McEntire wrote:
There is a serious bug in the VCL that will eat up atoms in the private atom table. Windows has a limited number of private atoms in the private atom table (32767), and this is shared by Windows classes, Windows Messages, Clipboard formats, etc. Every time the controls module is initialized, it creates a new Windows Message:

ControlAtomString := Format('ControlOfs%.8X%.8X', [HInstance, GetCurrentThreadID]);
ControlAtom := GlobalAddAtom(PChar(ControlAtomString));
RM_GetObjectInstance := RegisterWindowMessage(PChar(ControlAtomString));

The problem is multiplied by the number of DLL's that the application contains that includes the controls module. If you have 10 dll's, and one application, this code will consume 11 atoms every time it is ran.

When the system is ran out of atoms in the private atom table, no window class can be registered. This means, no windowed programs will be able to open after the private atom table is full.

These window messages cannot be deleted - there is simply no call to delete them that is exposed (there are calls in win32k.sys, but they cannot be accessed by the application). These atoms are deleted after the user logs out of windows, so this may not affect you. However, if your application is spawning processes, this can take the entire system down.

For my use, I have solved this by modifying controls.pas, including it directly in my c++ builder application, and changing the offending line as follows:

RM_GetObjectInstance := WM_USER+199; // an unused WM_USER message
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable.Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 5, 2014 8:40 PM   in response to: Steve Faleiro in response to: Steve Faleiro
Steve wrote:

Thanks for the fix available on EMBT CodeCentral!

That bug was fixed in the RTL in XE3.

--
Remy Lebeau (TeamB)
Steve Faleiro

Posts: 77
Registered: 3/11/01
Re: Serious bug in VCL eats up private atoms and makes sytem unstable.Beware.
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 5, 2014 8:45 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Steve wrote:

Thanks for the fix available on EMBT CodeCentral!

That bug was fixed in the RTL in XE3.

--
Remy Lebeau (TeamB)

...and by Andreas Hausladen for prior Delphi versions! Thank you Andy! :)

http://andy.jgknet.de/blog/bugfix-units/vclfixpack-10/

See the download on the above page:
Fix for QC 90511 (Atom leak) 6-XE ControlsAtomFix1.7z 3.78 KB 2014-04-18

Good work, Andy!

--
Steve Faleiro

Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02