Watch, Follow, &
Connect with Us

Please visit our new home
community.embarcadero.com.


Welcome, Guest
Guest Settings
Help

Thread: Tokyo 10.2.2 breaks TMonitor with Memory Managers



Permlink Replies: 3 - Last Post: Jan 17, 2018 10:15 AM Last Post By: Dalija Prasnikar
Brandon Staggs

Posts: 683
Registered: 3/3/01
Tokyo 10.2.2 breaks TMonitor with Memory Managers
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2018 9:25 PM
If you use anything other than the system.pas/getmem.inc memory
manager, and make any use of threads, you will want to know about this
very crippling system.pas bug in Tokyo 10.2.2.

I've reported the bug and also a fix here, please vote for it:

https://quality.embarcadero.com/browse/RSP-19777

Looks like someone thought TMonitor needed to do an end-run around
other memory managers, so it calls the low SysAllocMem routine on the
monitor, but GetMonitor will still free the same pointer with the
regular FreeMem call that goes through the registered memory manager.
What then follows are good old fashioned hard-to-reproduce thread
bugs.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo 10.2.2 breaks TMonitor with Memory Managers
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 17, 2018 6:24 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
If you use anything other than the system.pas/getmem.inc memory
manager, and make any use of threads, you will want to know about this
very crippling system.pas bug in Tokyo 10.2.2.

I've reported the bug and also a fix here, please vote for it:

https://quality.embarcadero.com/browse/RSP-19777

Looks like someone thought TMonitor needed to do an end-run around
other memory managers, so it calls the low SysAllocMem routine on the
monitor, but GetMonitor will still free the same pointer with the
regular FreeMem call that goes through the registered memory manager.
What then follows are good old fashioned hard-to-reproduce thread
bugs.

Nice catch. Of course it would be better if there was nothing to catch in
the first place.

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Brandon Staggs

Posts: 683
Registered: 3/3/01
Re: Tokyo 10.2.2 breaks TMonitor with Memory Managers
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 17, 2018 6:37 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
{quote:title=Dalija Prasnikar wrote:}
Nice catch. Of course it would be better if there was nothing to catch in
the first place.

Given than this particular bug only appears when you are using a third party memory manager and also happen to do something that calls TMonitor.Enter when the object is already locked, and therefore you are messing around in threads, you can imagine how hard this one was to track down. I wouldn't mind billing Emba for the 5 hours it took to figure this out. :-) TMonitor is used in various places in RTL so it will eventually affect more people using FastMM4 for debugging purposes (I use ScaleMM2).

This one is a good case to study why it is important not to librally toss finalization code across a unit, especially one as massive as system.pas. Somebody looked at TMonitor and figured that .Destroy was the only place the pointer is freed, and made a change to it. Indeed it would make sense, but since GetMonitor also will free the pointer, it gets instantly harder to refactor the code without regression...

-Brandon
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Tokyo 10.2.2 breaks TMonitor with Memory Managers
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 17, 2018 10:15 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
{quote:title=Dalija Prasnikar wrote:}
Nice catch. Of course it would be better if there was nothing to catch in
the first place.

Given than this particular bug only appears when you are using a third party memory manager and also happen to do something that calls TMonitor.Enter when the object is already locked, and therefore you are messing around in threads, you can imagine how hard this one was to track down. I wouldn't mind billing Emba for the 5 hours it took to figure this out. :-) TMonitor is used in various places in RTL so it will eventually affect more people using FastMM4 for debugging purposes (I use ScaleMM2).

This one is a good case to study why it is important not to librally toss finalization code across a unit, especially one as massive as system.pas. Somebody looked at TMonitor and figured that .Destroy was the only place the pointer is freed, and made a change to it. Indeed it would make sense, but since GetMonitor also will free the pointer, it gets instantly harder to refactor the code without regression...

If it compiles, ship it :(

--
Dalija Prasnikar
Embarcadero MVP
https://dalijap.blogspot.com/
Delphi Memory Management for Classic and ARC Compilers
https://dalija.prasnikar.info/delphimm/
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02