View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004429 | JEDI VCL | 00 JVCL Components | public | 2008-08-20 07:05 | 2008-12-22 05:49 |
Reporter | alexn | Assigned To | obones | ||
Priority | normal | Severity | crash | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 3.33 | ||||
Target Version | Fixed in Version | ||||
Summary | 0004429: Invalid pointer operation in TJvInspector (3.34 and 3.33) | ||||
Description | When closing application that uses TJvInspector an invalid pointer operation happens. This happens every time if any instance of TJvInspector is present at that time, at least under WinXP Prof and compiled with BDS 2007. This error never happen if no instances of TJvInspector are present. So, it seems that something is wrong with the object destruction order in the finalization section. | ||||
Additional Information | If found the following problem in the source code of JvInspector.pas: 1. TJvCustomInspectorItem has FItems of type TObjectList and TJvCustomInspectorItem.Create creates it owning containing objects - TObjectList.Create(True). But see TJvCustomInspectorItem.BeforeDestruction - it calls Parent.FItems.Remove, that kills it twice. As soon as FItems.Remove is called only from TJvCustomInspectorItem.BeforeDestruction, I think the best solution is to make FItems NOT owning containing objects - FItems := TObjectList.Create(False). 2. Take a look at next lines of TJvCustomInspectorItem.BeforeDestruction: it calls FData.RemoveItem(Self). And in RemoveItem you will see that it will call Destroy as soon as no more items are present there. But this code should return to the same Data in TJvCustomInspectorData.BeforeDestruction !!! And right here a error happens. Right now it seems for me the only solution is to remove the following code from TJvCustomInspectorItem.RemoveItem: ...if Length(FItems) = 0 then Destroy;... I had not checked for cross-links in this case. 3. In the finalization section all calls are FreeAndNil(...). And actually they do set all the variables to nil right at the time they enter the destructors. So, all the following code that should release registered objects works wrong - it will create a new instance of TJvInspDataReg for GlobalDataRegister. I think instead of FreeAndNil should a xxx.Free and then xxx := nil be used. | ||||
Tags | No tags attached. | ||||
|
Please provide the zipped sources of a sample application showing this. The demo does not exhibit this issue (at least here). |
2008-09-26 06:40
|
FailTest.zip (383,117 bytes) |
|
I had uploaded the source code for this bug. I suppose, the problem may be related to MDI style of the application. |
|
Ok, thanks for the demo. Issue available for anyone to look at. |
|
I downloaded 3.35 version on JVCL - the problem is not present there. But in 3.35 is present another problem - when trying to add 2 identically named event-driven properties, JvInspector cannot recognise that 2 copies and that causes failure. To resolve the problem, should make extra changes in the source code: 1. Add a field FParent: TJvCustomInspectorItem to TJvInspectorEventData 2. Assign that field to AParent in TJvInspectorEventData.New 3. Add a condition to TJvInspectorEventData.IsEqualReference: ... and (TJvInspectorEventData(Ref).FParent = FParent) But the code of all IsEqualReference is the same in 3.33, 3.34 and 3.35 - so that bug should be also present in all previous versions. But no exceptions were raised in my code in old versions, so the main problem is somewhere deeper. My solution for 3.33/3.34 posted previously helps, but periodically an AV still was happening at program close. With the latest 3.35 and the patch I described ealier no AV happened. |
|
The latest proposed change is in SVN. |
Date Modified | Username | Field | Change |
---|---|---|---|
2008-08-20 07:05 | alexn | New Issue | |
2008-09-03 09:21 | obones | Note Added: 0014531 | |
2008-09-03 09:21 | obones | Status | new => feedback |
2008-09-26 06:40 | alexn | File Added: FailTest.zip | |
2008-09-26 06:43 | alexn | Note Added: 0014698 | |
2008-10-10 05:09 | obones | Note Added: 0014816 | |
2008-10-10 05:09 | obones | Status | feedback => acknowledged |
2008-11-26 01:55 | alexn | Note Added: 0015065 | |
2008-12-22 05:42 | obones | Relationship added | related to 0004486 |
2008-12-22 05:49 | obones | Note Added: 0015154 | |
2008-12-22 05:49 | obones | Status | acknowledged => resolved |
2008-12-22 05:49 | obones | Resolution | open => fixed |
2008-12-22 05:49 | obones | Assigned To | => obones |