TDatamodule problem on Delphi XE2 [Edit]

I reported a problem to QC (#100324) that I think is related with this issue.
I've a project that I'm trying to compile with Delphi XE2 and when I close the application or close a form that links to the datamodule where my main connection to Interbase database is located, I'm
geting this error message:

First chance exception at $0061BCEA. Exception class $C0000005 with message 'access violation at 0x0061bcea: read of address 0x80808088'. Process Fac2011.exe (5608)

For example, I have a form with a TIBTransaction and a TIBQuery that are linked to a TIBDatabase that belongs to a TDatamodule. The data is displayed on a TDBGrid using a TDatasource.
It's a table with 2 columns, a simple select statetment, TIBQuery open and close.
When I close the form, free it, I get the presented error message.

When run with Debugger, after the error is presented, I press break and the debugger allways stop at line #890 of Unit System.Generics.Collections.
I'd try to set the new property to System.Classes.TPersistent and also to Vcl.Controls.TControl but I get allways the same error.
I have some procedures and functions defined on that TDatamodule that mainly access the TIBDatabase.
I'd try to convert that TDatamodule to a TForm but no go.

I don't know what else to do.
Some help would be appreciated. Delphi XE2 is a great product but all my projects are linked this way, to TDatamodules and I need this to work in order to decide to or not to buy Delphi XE2.
Thanks

I did some more digging with the Debugger and the error is raized on line 12686 (Instance.Destroy;) and Instance is reference to my TDatamodule.

Edited by: Carlos Matos on Oct 24, 2011 11:00 AM
0
Carlos
10/24/2011 6:03:16 PM
embarcadero.delphi.vcl.using 2297 articles. 2 followers. Follow

18 Replies
1741 Views

Similar Articles

[PageSpeed] 33
Get it on Google Play
Get it on Apple App Store

<Carlos Matos> wrote in message news:413624@forums.embarcadero.com...

> First chance exception at $0061BCEA. Exception class
> $C0000005 with message 'access violation at 0x0061bcea:
> read of address 0x80808088'. Process Fac2011.exe (5608)

Some memory managers use a bit pattern like 0x80808080 to fill in freed 
memory, usually in debug mode to help catch coding mistakes that access 
freed memory.  Since the error is being reported for a memory address just 8 
bytes offset from that bit pattern, my guess is that your MainForm code is 
trying to access a component that has already been freed beforehand.  Use 
the debugger and the call stack to find out what code is accessing the 
memory, and when and where that memory is getting freed.

> When run with Debugger, after the error is presented, I press break
> and the debugger allways stop at line #890 of Unit 
> System.Generics.Collections.

What does the debugger's Call Stack show?

-- 
Remy Lebeau (TeamB)
0
Remy
10/24/2011 6:04:43 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}
> Some memory managers use a bit pattern like 0x80808080 to fill in freed 
> memory, usually in debug mode to help catch coding mistakes that access 
> freed memory.  Since the error is being reported for a memory address just 8 
> bytes offset from that bit pattern, my guess is that your MainForm code is 
> trying to access a component that has already been freed beforehand.  Use 
> the debugger and the call stack to find out what code is accessing the 
> memory, and when and where that memory is getting freed.
> 
> > When run with Debugger, after the error is presented, I press break
> > and the debugger allways stop at line #890 of Unit 
> > System.Generics.Collections.
> 
> What does the debugger's Call Stack show?
{quote}

It shows:

=> System.Classes.TComponent.DestroyComponents
Vcl.Forms.DoneApplication
System.SysUtils.DoExitProc
System._Halt0
MyApp.MyApp
:75fb339a kernel32.BaseThreadInitThunk + 0x12
:77cd9ed2 ntdll.RtlInitializeExceptionChain + 0x63
:77cd9ea5 ntdll.RtlInitializeExceptionChain + 0x36
0
Carlos
10/24/2011 7:40:02 PM
<Carlos Matos> wrote in message news:413668@forums.embarcadero.com...

> It shows:
>
> => System.Classes.TComponent.DestroyComponents
> Vcl.Forms.DoneApplication
> System.SysUtils.DoExitProc
> System._Halt0
> MyApp.MyApp
> :75fb339a kernel32.BaseThreadInitThunk + 0x12
> :77cd9ed2 ntdll.RtlInitializeExceptionChain + 0x63
> :77cd9ea5 ntdll.RtlInitializeExceptionChain + 0x36

Why are you calling Halt()?  Closing the MainForm exits the application 
automatically.  If you want to exit manually, use the 
TApplication.Terminate() method.

DoneApplication() is called during application shutdown, after the main 
message loop has been terminated and the process is cleaning up after 
itself.  DoneApplication() frees any components that are Owned by the global 
TApplication object.  Are any of your DB components, or the TDataModule, 
owned by the TApplication object?

-- 
Remy Lebeau (TeamB)
0
Remy
10/24/2011 8:26:01 PM
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:413677@forums.embarcadero.com...

> Are any of your DB components, or the TDataModule, owned
> by the TApplication object?

In what order to you create the TDataModule and TForm that uses it? Does the 
TDataModule have any references to the TForm components?  If so, is the 
TForm being freed before the TDataModule?  Since the TForm components are 
linked to the TDataModule component(s), is the TDataModule being freed 
before the TForm?

-- 
Remy Lebeau (TeamB)
0
Remy
10/24/2011 8:28:27 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}
> In what order to you create the TDataModule and TForm that uses it?
{quote}
As I posted above.

> {quote:title=Remy Lebeau (TeamB) wrote:}
> Does the TDataModule have any references to the TForm components? 
{quote}
Yes it has. The TDatamodule (DLib) references some Main form components.

> {quote:title=Remy Lebeau (TeamB) wrote:}
> If so, is the TForm being freed before the TDataModule?  Since the TForm components are 
> linked to the TDataModule component(s), is the TDataModule being freed 
> before the TForm?
{quote}
I don't know if the Main form is being freed before the TDatamodule,but I think not,because
as I said I'm just closing the Main form to shutdown my application.
0
Carlos
10/24/2011 9:26:14 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}
> Why are you calling Halt()?  Closing the MainForm exits the application 
> automatically.  If you want to exit manually, use the 
> TApplication.Terminate() method.
> 
> DoneApplication() is called during application shutdown, after the main 
> message loop has been terminated and the process is cleaning up after 
> itself.  DoneApplication() frees any components that are Owned by the global 
> TApplication object.  Are any of your DB components, or the TDataModule, 
> owned by the TApplication object?
{quote}

I'm not calling Halt() at all,I'm just closing the Main form as I allways do.
The TDatamodule is created on the fly, on the Initialization of the app, like the Main form.

The sequence is:
Application.CreateForm(TMainProg, MainProg);  => Main form (linked to DLib)
Application.CreateForm(TFFichs,FFichs);          => Some code for creating main database and tables (linked to DLib)
Application.CreateForm(TDLib, DLib);                => My TDatamodule


And why this work just fine with Delphi 2010 ? Just try to understand if something was changed in Delphi XE2.
0
Carlos
10/24/2011 10:08:40 PM
<Carlos Matos> wrote in message news:413701@forums.embarcadero.com...

>> {quote:title=Remy Lebeau (TeamB) wrote:}
>> In what order to you create the TDataModule and TForm that uses it?
>{quote}
> As I posted above.

No, you did not, actually, otherwise I would not have had to ask.  Is the 
TDataModule instantiated before the TForm, or the other way around?  What 
are you setting the Owner to for each?

>> {quote:title=Remy Lebeau (TeamB) wrote:}
>> Does the TDataModule have any references to the TForm components?
> {quote}
> Yes it has. The TDatamodule (DLib) references some Main form components.

"references some components" and "having references to components" are two 
different things.

When I said "have any references", I meant does the TDataModule have any 
member variables that the MainForm components are assigned to?  If so, then 
if the TForm gets freed before the TDataModule, are you resetting those 
variables to nil, and checking them for nil before access them?  Any time 
you store component references, you should be using the 
TComponent.FreeNotification() to get notified when the components are freed 
so you can clear your references.

Or do you just access the components using a pointer to the MainForm and 
pointers to its member components every time without storing them anywhere 
else?

> I don't know if the Main form is being freed before the TDatamodule

Well, you need to figure that out.

> I think not,because as I said I'm just closing the Main form to shutdown 
> my application.

That does not mean anything.  Your exception is occuring when components are 
being freed, so you need to figure out what is being freed and in what 
order.  This also goes back to the earlier question of which order are you 
creating the TForm and TDataModule in.  If they have the same Owner (ie the 
TApplication object), that dicates the order in which they get freed by the 
Owner.

-- 
Remy Lebeau (TeamB)
0
Remy
10/25/2011 12:38:37 AM
<Carlos Matos> wrote in message news:413716@forums.embarcadero.com...

> The TDatamodule is created on the fly, on the Initialization
> of the app, like the Main form.

TApplication.CreateForm() assigns the TApplication object as the Owner.  Now 
that you have shown some more code, you are creating the MainForm before 
creating the TDataModule, which means the TDataModule will be freed before 
the MainForm is freed (owned components are freed in reverse owner).

What is TFFichs and how is it related to your design?  How EXACTLY are 
TMainProg, TFFichs, and TDLib related to each other?

-- 
Remy Lebeau (TeamB)
0
Remy
10/25/2011 12:41:19 AM
> It shows:
> 
> => System.Classes.TComponent.DestroyComponents
> Vcl.Forms.DoneApplication
> System.SysUtils.DoExitProc
> System._Halt0
> MyApp.MyApp
> :75fb339a kernel32.BaseThreadInitThunk + 0x12
> :77cd9ed2 ntdll.RtlInitializeExceptionChain + 0x63
> :77cd9ea5 ntdll.RtlInitializeExceptionChain + 0x36

I may be completely wrong in this case, but compiler-generated calls to _Release on stale interface references can be a typical cause of crashes on shutdown. So, does the data module or any of the forms implement any interfaces?
0
Chris
10/25/2011 12:56:15 AM
Carlos Matos wrote:
> I reported a problem to QC (#100324) that I think is related with this issue.
> I've a project that I'm trying to compile with Delphi XE2 and when I close the application or close a form that links to the datamodule where my main connection to Interbase database is located, I'm
> geting this error message:
> 
> First chance exception at $0061BCEA. Exception class $C0000005 with message 'access violation at 0x0061bcea: read of address 0x80808088'. Process Fac2011.exe (5608)
> 
> For example, I have a form with a TIBTransaction and a TIBQuery that are linked to a TIBDatabase that belongs to a TDatamodule. The data is displayed on a TDBGrid using a TDatasource.
> It's a table with 2 columns, a simple select statetment, TIBQuery open and close.
> When I close the form, free it, I get the presented error message.
> 
> When run with Debugger, after the error is presented, I press break and the debugger allways stop at line #890 of Unit System.Generics.Collections.
> I'd try to set the new property to System.Classes.TPersistent and also to Vcl.Controls.TControl but I get allways the same error.
> I have some procedures and functions defined on that TDatamodule that mainly access the TIBDatabase.
> I'd try to convert that TDatamodule to a TForm but no go.
> 
> I don't know what else to do.
> Some help would be appreciated. Delphi XE2 is a great product but all my projects are linked this way, to TDatamodules and I need this to work in order to decide to or not to buy Delphi XE2.
> Thanks
> 
> I did some more digging with the Debugger and the error is raized on line 12686 (Instance.Destroy;) and Instance is reference to my TDatamodule.
> 
> Edited by: Carlos Matos on Oct 24, 2011 11:00 AM

While not necessarily your problem, IBX has some AV problems in the current 
release when destroying a TIBDatabase with open connection/transactions.  All 
these should be resolved in the upcoming patch.  To lessen this make sure there 
is always a default database assigned to the transaction.  Before destroying the 
datamodule manually make sure the transaction is committed and the connection is 
closed so it does not go through the destruction phase with these active (most 
of the problems were timing issues that the database was destroyed before the 
transaction committed itself so if you do all this before the destruction phase 
most of the issues stop happening).

At this time I have no outstanding AV problems during destruction phase and that 
code has been turned in for patch #2.  I do not know the eta for patch #2 though 
(nor could I disclose it if I did know).

-- 
Jeff Overcash (TeamB)
       (Please do not email me directly unless  asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted  corridors of Whitehall.
              (Fish)
0
Jeff
10/25/2011 4:11:44 AM
> {quote:title=Remy Lebeau (TeamB) wrote:}
> TApplication.CreateForm() assigns the TApplication object as the Owner.  Now 
> that you have shown some more code, you are creating the MainForm before 
> creating the TDataModule, which means the TDataModule will be freed before 
> the MainForm is freed (owned components are freed in reverse owner).
> 
> What is TFFichs and how is it related to your design?  How EXACTLY are 
> TMainProg, TFFichs, and TDLib related to each other?
{quote}

First of all let me thank you Remy for your time.
Well, all this allways worked in all version of Delphi and let me say that I'm with Delphi since Delphi 4.
With Delphi 2010 this works just fine, Delphi 2007 too.
TMainProg is the main form of the app and it has some IBQuerys and some IBTransactions that are linked to a TIBDatabase that is on TDatamodule.
But when I close the main form (to shutdown the app), I'm pretty sure that I'm not accessing anything on TDatamodule. And I'm sure that when I close the main form,
I don't have any transaction active or querys.
About your last question, TFFichs has some TIBSQL the are linked to a TIBDatabase and a TIBTransaction on TMainProg. Also has some TIBSQL that are linked to a TIBDatabase on
the TDatamodule. TDlib has some TIBTransaction that are linked to the TIBDatabase on TMainProg and some TIBSQL also.

But once again, this works just fine with previous versions of Delphi, my last one and that my last registered version, Delphi 2010.

Isn't this related to what Jeff's says bellow?
I took the liberty to put this link (www.comograma.pt/files/Test.zip). If you open the project and try to clean, for instance, the Database property of IBSQL1, see what happens.
I'm getting this error on the IDE:

Access violation at address 0F6E2AE4 in module 'ibxpress160.bpl'. Read of address 0000004.

[0F6E2AE4]{ibxpress160.bpl} IBDatabase.TIBDatabase.GDSLibrary (Line 2183, "IBDatabase.pas" + 1) + $2
[0F6F139A]{ibxpress160.bpl} IBSQL.TIBSQL.SetDatabase (Line 2893, "IBSQL.pas" + 3) + $5
[5008C04A]{rtl160.bpl  } System.TypInfo.SetOrdProp (Line 2109, "System.TypInfo.pas" + 33) + $0
[20FCBE16]{designide160.bpl} DesignEditors.TPropertyEditor.SetOrdValue (Line 839, "DesignEditors.pas" + 2) + $E
[20FCDABA]{designide160.bpl} DesignEditors.TComponentProperty.SetValue (Line 1827, "DesignEditors.pas" + 9) + $4
[2113DEF3]{vclide160.bpl} IDEInspListBox.TInspListBox.SetPropValue (Line 782, "IDEInspListBox.pas" + 38) + $19
[2113FD2E]{vclide160.bpl} IDEInspListBox.TInspListBox.WMLButtonDown (Line 1544, "IDEInspListBox.pas" + 5) + $7
[50332830]{vcl160.bpl  } Vcl.Controls.TControl.WndProc (Line 7204, "Vcl.Controls.pas" + 91) + $6
[500B5DF8]{rtl160.bpl  } System.Classes.StdWndProc (Line 13878, "System.Classes.pas" + 8) + $0
[5033717B]{vcl160.bpl  } Vcl.Controls.TWinControl.WndProc (Line 9976, "Vcl.Controls.pas" + 152) + $6
[5003D48B]{rtl160.bpl  } System.TMonitor.TryEnter (Line 14707, "System.pas" + 10) + $0
[5003D000]{rtl160.bpl  } System.TMonitor.Enter (Line 14410, "System.pas" + 4) + $2
[5003CEA4]{rtl160.bpl  } System.TMonitor.CheckOwningThread (Line 14332, "System.pas" + 2) + $0
[5003D1AA]{rtl160.bpl  } System.TMonitor.Exit (Line 14521, "System.pas" + 9) + $7
[5003D1E3]{rtl160.bpl  } System.TMonitor.Exit (Line 14535, "System.pas" + 2) + $7
[5031362B]{vcl160.bpl  } Vcl.Graphics.FreeMemoryContexts (Line 7043, "Vcl.Graphics.pas" + 12) + $8
[50336A10]{vcl160.bpl  } Vcl.Controls.TWinControl.IsControlMouseMsg (Line 9753, "Vcl.Controls.pas" + 9) + $25
[5033717B]{vcl160.bpl  } Vcl.Controls.TWinControl.WndProc (Line 9976, "Vcl.Controls.pas" + 152) + $6
[5035A084]{vcl160.bpl  } Vcl.StdCtrls.TCustomListBox.WndProc (Line 6911, "Vcl.StdCtrls.pas" + 54) + $6
[503367D0]{vcl160.bpl  } Vcl.Controls.TWinControl.MainWndProc (Line 9689, "Vcl.Controls.pas" + 3) + $6
[500B5DF8]{rtl160.bpl  } System.Classes.StdWndProc (Line 13878, "System.Classes.pas" + 8) + $0
[5032D63E]{vcl160.bpl  } Vcl.Controls.FindControl (Line 3540, "Vcl.Controls.pas" + 6) + $9
[50451EC3]{vcl160.bpl  } Vcl.Forms.TApplication.ProcessMessage (Line 10161, "Vcl.Forms.pas" + 23) + $1
[50451F06]{vcl160.bpl  } Vcl.Forms.TApplication.HandleMessage (Line 10191, "Vcl.Forms.pas" + 1) + $4
[50452239]{vcl160.bpl  } Vcl.Forms.TApplication.Run (Line 10328, "Vcl.Forms.pas" + 26) + $3


and what can't ever clear that property. Same thing if you try to clear Database property of the TIBQuery1.
0
Carlos
10/25/2011 10:18:19 AM
> {quote:title=Chris Rolliston wrote:}
> I may be completely wrong in this case, but compiler-generated calls to _Release on stale interface references can be a typical cause of crashes on shutdown. So, does the data module or any of the forms implement any interfaces?
{quote}

No Chris, it doesn't.
0
Carlos
10/25/2011 10:19:33 AM
> {quote:title=Jeff Overcash wrote:}
> While not necessarily your problem, IBX has some AV problems in the current 
> release when destroying a TIBDatabase with open connection/transactions.  All 
> these should be resolved in the upcoming patch.  To lessen this make sure there 
> is always a default database assigned to the transaction.  Before destroying the 
> datamodule manually make sure the transaction is committed and the connection is 
> closed so it does not go through the destruction phase with these active (most 
> of the problems were timing issues that the database was destroyed before the 
> transaction committed itself so if you do all this before the destruction phase 
> most of the issues stop happening).
> 
> At this time I have no outstanding AV problems during destruction phase and that 
> code has been turned in for patch #2.  I do not know the eta for patch #2 though 
> (nor could I disclose it if I did know).
{quote}

Jeff, I did some more digging and found that the error occurs always on line #2165 of IBDatabase:
FTransaction.RemoveSQLObject(Self);

and after this on line #818 of unit System.Generics.Collections and after this on line #890 of System.Generics.Collections.

I think that when it try to execute that line, FDatabase if nil and it raizes the error.
Do you think is related about what you said?

Edited by: Carlos Matos on Oct 25, 2011 8:00 AM

Also in any project, even in a new one with a few IB components, if I try to set in runtime, for instance, IBSQL.Database, I'll get the an error message.

Edited by: Carlos Matos on Oct 25, 2011 8:15 AM

Ok, this is defenetly a problem with this Delphi XE2 IBX components. I'd compiled my project using IBX source of Delphi 2010 with some changes for me to be able to
compile it and now my application runs perfectly.
0
Carlos
10/25/2011 3:18:12 PM
Carlos Matos wrote:

> Isn't this related to what Jeff's says bellow?
> I took the liberty to put this link (www.comograma.pt/files/Test.zip). If you open the project and try to clean, for instance, the Database property of IBSQL1, see what happens.
> I'm getting this error on the IDE:
> 

This does not happen in the current codebase with this project.  So should be 
fixed in Patch 2.

-- 
Jeff Overcash (TeamB)
       (Please do not email me directly unless  asked. Thank You)
And so I patrol in the valley of the shadow of the tricolor
I must fear evil. For I am but mortal and mortals can only die.
Asking questions, pleading answers from the nameless
faceless watchers that stalk the carpeted  corridors of Whitehall.
              (Fish)
0
Jeff
10/25/2011 5:02:20 PM
I was investigating why some internal processes failed during destruction for no apparent reason since upgrading to xe2 update2 from xe update 1. I was able to correct it by closing the transaction handle explicitly. After reading this article I created a sample app, see below, however it only occurs when using fastmm4 fulldebugmode version 4.99. Should I log this in qc, and if so where?


program XE2u2Destructor;

uses
  FastMM4,
  Vcl.Forms,
  UnitIBXE2u2 in 'UnitIBXE2u2.pas' {Form4};

{$R *.res}

begin
  ReportMemoryLeaksOnShutdown := true;

  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm4, Form4);
  Application.Run;
end.

unit UnitIBXE2u2;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls,DB, IBDatabase,IBQuery;

type
  TForm4 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form4: TForm4;

implementation

{$R *.dfm}

procedure TForm4.Button1Click(Sender: TObject);
const
  _CS_DATABASE_NAME_IB_SDW_TEST = 'IBSdw:f:\data\richlu-test.ib';
  _CS_DATABASE_SYS = 'sysdba';
  _CS_DATABASE_SYS_PAS = 'xxxxx';
var
  oQuery:TIBQuery;
  oTransaction:TIBTransaction;
  oDatabase:TIBDataBase;
begin
  //set used ID also!
    oDatabase := TIBDatabase.Create(nil);
    oTransaction := TIBTransaction.Create(nil);
    oQuery := TIBQuery.Create(nil);
    try
      oDatabase.DefaultTransaction := oTransaction;
      oDatabase.DatabaseName :=  _CS_DATABASE_NAME_IB_SDW_TEST;
      oDatabase.Params.Add( 'user_name='+_CS_DATABASE_SYS);
      oDatabase.Params.Add('password='+_CS_DATABASE_SYS_PAS);
      oDatabase.LoginPrompt := false;
      oDatabase.Open;
      with oTransaction do
      begin
        DefaultDatabase := oDatabase;
        DefaultAction := taRollBack;
        Params.add('read_committed');
        Params.add('rec_version');
        Params.add('nowait');
      end;

      with oQuery do
      begin
        Database := oDatabase;
        Transaction := oTransaction;
        if not Database.Connected then
          Database.Open;
        if not Transaction.InTransaction then
           Transaction.StartTransaction;
        Close;
        SQL.Text := Format('select * from IC_USER u where u.logon=''%s'' ',['ROPPITZ']);
        try
          Open;
          Button1.Caption := FieldByName('user_description').AsString;
          Close;
//          if Transaction.InTransaction then
            Transaction.Commit;
//          if Database.Connected then
            Database.Close;
        except
          on E:Exception do
          begin
            if Transaction.InTransaction then
              Transaction.RollBack;
            raise;
          end;
        end;
      end;
    finally
      oDatabase.DefaultTransaction := nil;
      oQuery.Free;
      oTransaction.Free;
      oDatabase.Free;
    end;
end;

end.

> {quote:title=Jeff Overcash wrote:}{quote}
> Carlos Matos wrote:
> 
> > Isn't this related to what Jeff's says bellow?
> > I took the liberty to put this link (www.comograma.pt/files/Test.zip). If you open the project and try to clean, for instance, the Database property of IBSQL1, see what happens.
> > I'm getting this error on the IDE:
> > 
> 
> This does not happen in the current codebase with this project.  So should be 
> fixed in Patch 2.
> 
> -- 
> Jeff Overcash (TeamB)
>        (Please do not email me directly unless  asked. Thank You)
> And so I patrol in the valley of the shadow of the tricolor
> I must fear evil. For I am but mortal and mortals can only die.
> Asking questions, pleading answers from the nameless
> faceless watchers that stalk the carpeted  corridors of Whitehall.
>               (Fish)
0
Ralf
11/12/2011 2:34:58 AM
Hi,

problem is somewhere in TSchema.

destructor TSchema.Destroy;
begin
  FreeNodes;
  FRelations.Free;
//at this time FQuery.FBase.FTransaction is nil and next line is OK
  FQuery.Free;
//at this time FPQuery.FBase.FTransaction is not nil and points to already freed block of memory.
  FPQuery.Free;
  inherited;
end;

Thanks,
Vladimir
0
Vladimir
11/14/2011 7:20:04 PM
Vladimir wrote:


> //at this time FPQuery.FBase.FTransaction is not nil and points to
> already freed block of memory.
> FPQuery.Free;

What is FPQuery and how is it assigned beforehand?  Is it an actual child 
component of TSchema, or is it a pointer to another component somewhere else? 
 If the former, then I would guess that it is linked to another component 
that is freeing it.  If the latter, then I would guess the other component 
is being freed and you are not updating your pointer.  Either way, try overriding 
the virtual Notification() method to see if FPQuery is being freed before 
the destructor is called, eg:

{code:delphi}
procedure TSchema.Notification(AComponent: TComponent; Operation: TOperation);
begin
  inherited;
  if (Operation = opRemove) and (AComponent = FPQuery) then
    FPQuery := nil;
end;
{code}

In the former case, make sure the TSchema is the Owner of the component so 
Notification() will be called.  In the latter case, make sure to call TComponent.FreeNotification() 
when FPQuery is assigned so Notification() will be called.

--
Remy Lebeau (TeamB)
0
Remy
11/14/2011 8:32:33 PM
> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Vladimir wrote:
> 
> 
> > //at this time FPQuery.FBase.FTransaction is not nil and points to
> > already freed block of memory.
> > FPQuery.Free;
> 
> What is FPQuery and how is it assigned beforehand?  Is it an actual child 
> component of TSchema, or is it a pointer to another component somewhere else? 
It's actual child of Tschema and is created in TSchema.Create.

>  If the latter, then I would guess the other component 
> is being freed and you are not updating your pointer.
>  Either way, try overriding 
> the virtual Notification() method to see if FPQuery is being freed before 
> the destructor is called, eg:
> 
> {code:delphi}
> procedure TSchema.Notification(AComponent: TComponent; Operation: TOperation);
> begin
>   inherited;
>   if (Operation = opRemove) and (AComponent = FPQuery) then
>     FPQuery := nil;
> end;
> {code}
> 
Not so easy. It's FBase that is child of FPQuery that got freed.

> In the former case, make sure the TSchema is the Owner of the component so 
> Notification() will be called.  In the latter case, make sure to call TComponent.FreeNotification() 
> when FPQuery is assigned so Notification() will be called.

That's question for the author, I'm just trying to pinpoint the problem.
0
Vladimir
11/14/2011 9:23:02 PM
Reply:

Web resources about - TDatamodule problem on Delphi XE2 [Edit] - embarcadero.delphi.vcl.using

Resources last updated: 1/19/2016 4:34:25 AM