Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2009-10

Object instance is suddenly corrupt or of unknown type?

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

I'm using FPC 2.3.1 on a 64bit Linux system.

I have a field variable which is an class instance. Many methods use this field variable and it's properties. I suddenly started getting Access Violations in my application. Adding that field variable to the Watch Window and stepping through my program I can see the problem.

Most of the times te watch output is: FLayout: TRichTextLayout 0xabcedef

This is correct. The type is known and the memory address seems fine. (ignore my fake mem address above).

But then at some point the watch output changes to: FLayout: ??? 0xabcedef

This is to be the problem! I can't seem to find out what cause the type to be unknown!! :-( My Access Violation, is because I checked if FLayout is assigned (which is true even with unknown type) and then try and Free it, which throws the AV.

At the point where the watch output changes to ???, I ask for a Call Stack, but the call stack window is incomplete, there are many extra methods called between the ones listen in the window.... why is that?

Anyway what is the correct way of passing a class instance (object) to methods? Maybe this is my problem?

eg: Which one is preferred or correct.

FLayout: TRichTextLayout (class instance)... then pass it to other procedures outside the current class.

Example procedure signature..

procedure TestOne(const ALayout: TRichTextLayout);     <-- currently using this

..or...

procedure TestOne(var ALayout: TRichTextLayout);

..or..

procedure TestOne(ALayout: TRichTextLayout);
Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/

Reply by email

Graeme Geldenhuys
to Graeme Geldenhuys

2009/10/8 Graeme Geldenhuys :

Anyway what is the correct way of passing a class instance (object) to methods? Maybe this is my problem?

Actually, I don't think this is the issue. There was only two places in my code where I pass the FLayout instance to external procedures. I used to use 'const' parameters and then removed the 'const', meaning I pass them by Value. This made no difference. My FLayout instances still seems to loose it's type information at some point. :-(

Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/

Reply by email

JoshyFun
to Graeme Geldenhuys: I'm using FPC 2.3.1 on a 64bit Linux system. I have a field variable which is an class…

Hello FPC-Pascal,

Thursday, October 8, 2009, 12:38:20 PM, you wrote:

GG> Most of the times te watch output is: FLayout: TRichTextLayout 0xabcedef GG> This is correct. The type is known and the memory address seems fine. GG> (ignore my fake mem address above).
GG> But then at some point the watch output changes to: FLayout: ??? 0xabcedef GG> This is to be the problem! I can't seem to find out what cause the GG> type to be unknown!! :-( My Access Violation, is because I checked if GG> FLayout is assigned (which is true even with unknown type) and then GG> try and Free it, which throws the AV.

From my experience this happends in two cases usually:

1) You free the memory of the class (.free) directly or using another variable which is referencing the same object. Something like:

  A:=XXX.Create();
  B:=A;
  [...Many lines of code...]
  B.Free;
  [...Many lines of code...]
  A.Free; //Crash...

2) Other more hard to detect is memory overwrite, so set all pascal runtime checks on. It happends in something like this:

  A: array [0..9] of char;
  B: TMyClass;
  C: String;
  [...Many lines of code...]
  C:='This are more than 10 chars';
  Move(C[1],A[0],Length(C));
  B.Free; //Crash...

This will not be detected by runtime checks and I think it will not also detected by heaptrc memory verifications. So take a look over the prior declared variables, specially is they are arrays. As you are running linux valgrind should help you.

Best regards, JoshyFun

Reply by email