View Issue Details

IDProjectCategoryView StatusLast Update
0004429JEDI VCL00 JVCL Componentspublic2008-12-22 05:49
ReporteralexnAssigned Toobones 
Status resolvedResolutionfixed 
Product Version3.33 
Target VersionFixed in Version 
Summary0004429: Invalid pointer operation in TJvInspector (3.34 and 3.33)
DescriptionWhen 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.
TagsNo tags attached.


related to 0004486 resolvedAHUser TJvInspector: Lost input focus in MDI never comes back 



2008-09-03 09:21

administrator   ~0014531

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 (383,117 bytes)


2008-09-26 06:43

reporter   ~0014698

I had uploaded the source code for this bug. I suppose, the problem may be related to MDI style of the application.


2008-10-10 05:09

administrator   ~0014816

Ok, thanks for the demo.
Issue available for anyone to look at.


2008-11-26 01:55

reporter   ~0015065

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.


2008-12-22 05:49

administrator   ~0015154

The latest proposed change is in SVN.

Issue History

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:
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