Project JEDI - Issue Tracker
Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003200 [JEDI VCL] 00 JVCL Components major always 2005-09-16 07:17 2005-11-22 03:29
Reporter boerema1 View Status public  
Assigned To AHUser
Priority normal Resolution fixed  
Status resolved   Product Version 3.00
Summary 0003200: Using LinkedControls in combination with FastMM4 results in AV because of attempt to call a virtual method on a freed object
Description When using FastMM4 (version 4.27) as memory manager and using LinkedControls in my options form (JvCheckBox.LinkedControls property) I get an AV.

I have attached an example project. Everything works OK when LinkedControls property is empty, but when I set a control as LinkedControl I get an AV when closing (destroying) the form. Looking at the report I think the problem lies somewhere in LinkedControls.

FastMM4 reports this:

FastMM has detected an attempt to call a virtual method on a freed object. An access violation will now be raised in order to abort the current operation.

Freed object class: TEdit

Virtual method: Offset +100

Virtual method address: 4393FC

Stack trace of when the object was allocated (return addresses):
4029D3 [System][@GetMem]
42091A [Classes][TReader.ReadComponent]
420B66 [Classes][TReader.ReadDataInner]
420AD4 [Classes][TReader.ReadData]
424C1A [Classes][TComponent.ReadState]
420985 [Classes][TReader.ReadComponent]
420B66 [Classes][TReader.ReadDataInner]
420AA5 [Classes][TReader.ReadData]
424C1A [Classes][TComponent.ReadState]

Stack trace of when the object was subsequently freed (return addresses):
4029F3 [System][@FreeMem]
403843 [System][TObject.Free]
43D730 [Controls][TWinControl.WndProc]
43D3AB [Controls][TWinControl.MainWndProc]
425826 [Classes][StdWndProc]
BFF63613 [ThunkConnect32]
BFF848F7 [UTUnRegister]

The current stack trace leading to this error (return addresses):
4601B6 [JvLinkedControls.pas][JvLinkedControls][TJvLinkedControl.Destroy][139]
41D62F [Classes][TCollection.Destroy]
403843 [System][TObject.Free]
43D730 [Controls][TWinControl.WndProc]
43D3AB [Controls][TWinControl.MainWndProc]
425826 [Classes][StdWndProc]
BFF63613 [ThunkConnect32]
BFF848F7 [UTUnRegister]

I'm using D6, with JVCL and JCL of September 8.
Additional Information
Tags No tags attached.
Attached Files zip file icon [^] (1,765 bytes) 2005-09-16 07:17
zip file icon [^] (2,173 bytes) 2005-11-17 12:32

- Relationships

-  Notes
Kiriakos (reporter)
2005-11-11 16:27

I have had the same problem using D2005.

In your FormDestroy event handler clear the LinkedControls manually.


Modify the following two mehtods:

procedure TJvCheckBox.Notification(AComponent: TComponent;
  Operation: TOperation);
  inherited Notification(AComponent, Operation);
  // commented out the second condition
  if Assigned(FLinkedControls) {and not (csDestroying in ComponentState) }then
    LinkedControls.Notification(AComponent, Operation);

procedure TJvLinkedControls.Notification(AComponent: TComponent; Operation: TOperation);
  I: Integer;
  // make sure the owning control isn't being destroyed
// commented out the following two lines
// if Assigned(FControl) and (csDestroying in FControl.ComponentState) then
// Exit;
    if (AComponent is TControl) and (Operation = opRemove) then
      for I := 0 to Count - 1 do
        if Items[I].Control = AComponent then
          Items[I].Control := nil;

Notification methods should never check whether the component is being destroyed. This is all taken care of by the VCL. As it stands, on form destruction the linked control is not removed from the notification list of JvCheckBox. When the JvCheckBox itself is destroyed, JvCheckbox tries to remove itself from the notification list of the linked control which is already destroyed. Kudos to FastMM for discovering yet another hard to trace bug.
Kiriakos (reporter)
2005-11-11 16:57

Since the author of LinkedComponents is Peter who also contributed many other components, it could be worth checking the Notification handlers in other components of JVCL to make sure they don't suffer from the same problem.
boerema1 (reporter)
2005-11-17 12:30

This solution seems to resolve the AV, at least in the test case. BTW. I saw that my test project was incomplete. I'll upload a new version.

As suggested I checked for other components also checking for being destroyed in the Notification handler. The following files have this (files from 10 november 2005):

AHUser (developer)
2005-11-22 03:29

Fixed in CVS for


- Issue History
Date Modified Username Field Change
2005-09-16 07:17 boerema1 New Issue
2005-09-16 07:17 boerema1 File Added:
2005-11-11 16:27 Kiriakos Note Added: 0008084
2005-11-11 16:57 Kiriakos Note Added: 0008086
2005-11-17 12:30 boerema1 Note Added: 0008095
2005-11-17 12:32 boerema1 File Added:
2005-11-22 03:29 AHUser Status new => resolved
2005-11-22 03:29 AHUser Resolution open => fixed
2005-11-22 03:29 AHUser Assigned To => AHUser
2005-11-22 03:29 AHUser Note Added: 0008107

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker