Freeing a data module which contains a TJvAppDBStorage raises an access violation in TComponent.RemoveNotification()

Question

I have a data module which I can not free (funny as it might sound). Whether I try to destroy it manually, or let another component (even Application) do it for me, I get an AV with this stack trace:

exception class   : EAccessViolation
exception message : Access violation at address 0048FC2B in module 'Instruments.exe'. Read of address 80808088.

main thread ($1e28):
0048fc2b Instruments.exe System.Classes    TComponent.RemoveNotification
00408a01 Instruments.exe System         57 @Halt0
00ac86f0 Instruments.exe Instruments    82 initialization

This data module contains a bunch of TADOxxx components, plus two TJvDataSource, one TApplicationEvents, one TClientDataSet, and one TJvAppDBStorage. Its code contains nothing more than opening the ADO connection, writing a few records to a table, running a few queries, etc. (nothing unusual). It doesn't own any other components besides what I mentioned above. I'm puzzled as to where does this bogus call to RemoveNotificaion() originate from. Any ideas?

UPDATE

After removing the TJvAppDBStorage, I can destroy the data module. Here's the component's properties:

object AppStorage: TJvAppDBStorage
  StorageOptions.BooleanStringTrueValues = 'TRUE, YES, Y'
  StorageOptions.BooleanStringFalseValues = 'FALSE, NO, N'
  DataSource = dsConfiguration
  KeyField = 'Key'
  SectionField = 'Section'
  SubStorages = <>
  ValueField = 'Value'
  Left = 272
  Top = 304
end

Has anyone ever used JvAppDBStorage? Is this its normal and expected behavior?

Answer 1

I've no experience with JvAppDBStorage but I can make a guess as to what is happening.

This component stores settings to a database, as specified by the DataSource property of the JvAppDBStorage instance. In your case that is dsConfiguration. So, for this all to work you need for dsConfiguration to be available whenever AppStorage reads and writes settings. I'll bet that dsConfiguration has already been destroyed when AppStorage attempts to store to it. I expect that happens when AppStorage is freed. So the explanation for the problem is that dsConfiguration is freed before AppStorage.

The solution will be to make sure that dsConfiguration is still alive when AppStorage is freed.