StatusBarPro Bug (v. 1.7)

[Greg Chapman]

Using StatusBarPro (v. 1.7), I can cause an access violation in Delphi 5 (Windows XP) with the following steps:

1. Create new form, drop a TStatusBarPro on it
2. Add a panel to the statusbar
3. Drop a TProgressBar on the form, then set it as the control for the
panel.
4. Delete the statusbar (press the delete key with the statusbar
selected in the form designer).

I believe the problem may be that, when the child ProgressBar control is destroyed (in TWinControl.Destroy called on the StatusBar), an opRemove Notification is generated. This eventually reaches the StatusBar's Notification method, which attempts to check if the control is referenced by one of the panels. Unfortunately, the Panels collection has already been freed (during TStatusBarPro.Destroy).

I changed TStatusBarPro.Destroy to use FreeAndNil on FPanels, and then added an Assigned check to TStatusBarPro.Notification, and that seems to have fixed things (at least there's no more AV).

[Kambiz]

Did you try version 1.71 of the component? This bug is already fixed on the latest release.

[Greg Chapman]

Did you try version 1.71 of the component? This bug is already fixed on the latest release.

Interesting, that does fix the AV. However, I believe the problem I pointed out is real. If you use 1.71, but change FPanels.Free (in TStatusBarPro.Destroy) to FreeAndNil(FPanels), you will get an access violation in the Notification procedure (in the loop entered if AComponent is TControl). In other words, FPanels is being accessed after it is freed. Apparently, this works basically all the time, but I think nevertheless it should be fixed (it may break some day in a multi-threaded app if a heap allocation is made between when FPanels is freed and when the child control Notification is sent).

[Kambiz]

Regardless of calling either FPanels.Free or FreeAndNil(FPanels), FPanels doesn't point to a valid address. So, according to your description, in both cases the AV should occur.

In addition, while the ComponentState is csDestroying, delphi doesn't pass notifications to the component.

[Greg Chapman]

Sorry not to have replied earlier, I forgot to check if there had been a response to my previous post.

Regardless of calling either FPanels.Free or FreeAndNil(FPanels), FPanels doesn't point to a valid address. So, according to your description, in both cases the AV should occur.

In the first case (where FPanels is not set to nil), there is not necessarily an AV since the blocks for FPanels and FItems (the list it uses to actually store items) may both be still in the heap free area (probably in one of the small block lists), with most of their contents still intact -- in particular, the 0 in FItems.FCount which means the loop won't be executed. Using FreeAndNil guarantees an AV if there is an attempt to use FPanels after it is freed.

In addition, while the ComponentState is csDestroying, delphi doesn't pass notifications to the component.

The above is not true in D5. I traced the component destruction in the debugger. When TStatusBarPro calls inherited Destroy, control eventually reaches TComponent.Destroy. This eventually calls FOwner.RemoveComponent(Self). TComponent.RemoveComponent issues a Notification for the opRemove which is sent to all children, including the statusbarpro (it is not completely removed until the call to TComponent.Remove).

In D5 anyway, none of the above mechanism is affected by csDestroying.

Sorry again for not replying sooner and thanks for looking into this.

[Kambiz]

You were right, thanks!

I fixed the bug, and the update is available to download.