View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003200 | JEDI VCL | 00 JVCL Components | public | 2005-09-16 07:17 | 2005-11-22 03:29 |
| Reporter | boerema1 | Assigned To | AHUser | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.00 | ||||
| Target Version | Fixed in Version | 3.10 | |||
| 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] 6A8CE6 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] 6A8CE6 I'm using D6, with JVCL and JCL of September 8. | ||||
| Tags | No tags attached. | ||||
|
2005-09-16 07:17
|
LinkedControlsBug.zip (1,765 bytes) |
|
|
I have had the same problem using D2005. Workaround: In your FormDestroy event handler clear the LinkedControls manually. i.e. jvCheckBox1.LinkedControls.Clear; Solution: Modify the following two mehtods: procedure TJvCheckBox.Notification(AComponent: TComponent; Operation: TOperation); begin inherited Notification(AComponent, Operation); // commented out the second condition if Assigned(FLinkedControls) {and not (csDestroying in ComponentState) }then LinkedControls.Notification(AComponent, Operation); end; procedure TJvLinkedControls.Notification(AComponent: TComponent; Operation: TOperation); var I: Integer; begin // 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; BeginUpdate; try 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; finally EndUpdate; end; end; Explanation: 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. |
|
|
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. |
|
|
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): JvAppDBStorage.pas JvBackgrounds.pas JvCheckBox.pas JvFormPlacement.pas JvLinkedControls.pas JvListView.pas JvOutlookBar.pas JvRadioButton.pas JvStatusBar.pas JvXPBar.pas |
|
2005-11-17 12:32
|
LinkedControlsBug2.zip (2,173 bytes) |
|
|
Fixed in CVS for JvCheckBox.pas JvLinkedControls.pas JvRadioButton.pas |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-09-16 07:17 | boerema1 | New Issue | |
| 2005-09-16 07:17 | boerema1 | File Added: LinkedControlsBug.zip | |
| 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: LinkedControlsBug2.zip | |
| 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 |
