Strange EAccessViolation which I cannot figure out...

Hi everybody,

While working on my first delphi project, I came across a strange 
EAccessViolation which I can't seem to put my finger on... 

There's a separate unit which contains a class TFileInfo, this class has 
a procedure to add doubles, and a function to return the doubles. Doubles 
are stored in a TObjectList. While filling the TObjectList, I can access 
the Count variable just fine - but as soon as I return the TObjectList, I 
can't access the variable anymore. Neither can I do something with the 
list.

Here's the code:
--- unit ---
unit FileInfo;

interface

uses Windows, SysUtils, ContNrs;

type
  TFileInfo = class
    private
      dbls : TObjectList;
    public
      procedure addDouble(var f : TFileInfo);
      function getDoubles() : TObjectList;
  end;

implementation

procedure TFileInfo.addDouble(var f : TFileInfo);
begin
  if (dbls = nil) then
    begin
      dbls := TObjectList.Create;
    end;

  dbls.Add(f);

  // this works perfectly!
  OutputDebugString(pchar('---' + IntToStr(dbls.Count) + '---'));
end;

function TFileInfo.getDoubles() : TObjectList;
begin
  // yet this does not... let alone being able to access dbls!
  OutputDebugString(pchar(dbls.Count));
  result := dbls;
end;

end.
--- end unit ---

The exact error I receive is:
"First chance exception at $7C4EA4E1. Exception class EAccessViolation 
with message 'Access violation at address 004609A2 in module 'DFR.exe'. 
Read of address 30306176'. Process DFR.exe (1244)"

I've already tried to compare dbls against nil, but it seems it is not 
nil, which is supposed to be like that.

Can anybody please shed some light on this one? I have no idea what's 
gone wrong, or what I could do to rectify this issue...

Thanks in advance!

Ikke

"Ikke" < XXXX@XXXXX.COM > schreef in bericht 


      constructor create;
      procedure free;
constructor TfileInfo.create;
begin
  inherited;
  dbls:=TobjectList.create;
end;

procedure TfileInfo.free;
begin
  dbls.free;
  inherited;
end;

//>  if (dbls = nil) then
//>    begin
//>      dbls := TObjectList.Create;
//>    end;

You do not show how the proc and function are called.
If you call GetDoubles before you call AddDoubles, you will have an AV since 
dbls is then not yet assigned. The OutputDebugString call will then cause 
the error.

In general, it is a good idea to define a Create constructor where you 
create all the contained objects. The destructor will call FREE; that's the 
place where you can destroy them again. I have added them in your code (and 
removed the 'if dbls=NIL' (NB: you trust it will be set to NIL upon 
creation. Maybe that's the case, but better not depend on such beliefs.).
Tell us if you still get the error.
Tom

"Ikke" < XXXX@XXXXX.COM > wrote

Typecasting an integer as a pchar?

Try
  OutputDebugString(IntToStr(dbls.Count));




has
Doubles
access
TObjectList, I
the
EAccessViolation
'DFR.exe'.
not
what's

The lazy initialization of dbls is fine, as long as it's lazily 
initialized everywhere. At first glance, it would seem as though the 
access violation is coming from checking the Count property of an 
uninitialized dbls field in GetDoubles. But that's not the case. The 
indication of that is the address being read, $30306176. If dbls were 
uninitialized, the address would be $00000000, or something very close 
to it.

My guess is that the variable being used to invoke the GetDoubles method 
is not initialized.


You've got it backward. The non-virtual Free method calls the 
destructor. Override the destructor named Destroy.


Actually, it's defined by the language that all fields will be 
all-bits-zero when the constructor starts running. It's required to be 
that way because of how the destructor might get called before the 
constructor finishes running.

-- 
Rob

"Tom de Neef" < XXXX@XXXXX.COM > wrote in



<snip>
<snip>

Thanks to all who have replied - I can't try your suggestions/solutions 
right now, I'll try them in the morning.

One thing I'd quickly like to add, though, is that AddDoubles is indeed 
called prior to calling GetDoubles. Otherwise, I could indeed imagine an 
error popping up.

Thanks, and I'll reply tomorrow with the results!

Ikke

That's a perfectly safe assumption. Constructors are documented to 
always set their objects' fields to zero, nil, empty, or unassigned 
(depending on each field's type). In fact, the documentation says "there 
is no need to initialize fields in a constructor implementation except 
to nonzero or nonempty values."


Aha, yes, that's the real problem.

-- 
Rob

Sorry, you don't get it. If you don't set it to some fixed value at
start up, then in your code as you were using, you were testing for
the creation of the object just by testing for a NIL>
   In this case, you must either create the object of make sure you
clear the field to NIL>
   Regardless of what it saids in the help, I can tell you by experience
that you should not assume the class to Nil your fields for you 
automatically in the constructor.
   When memory is allocated, Delphi likes to zero it out, in this case
it will work how ever, if memory has been used already and it's still
in delphi's heap, it just simply gives you the memory. this means, what
ever was there before you get.

   The last time I knew, Delphi uses the option from the API to get a
zeroed chunk of memory..
   To speed things up, normally memory is not wiped while delphi has it
in it's own heap.


-- 
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
 http://www.**--****.com/ 

The Address 30306176 looks much more like 4 characters, than like a 
valid pointer.

DoDi

[...]

But that only applies during object _creation_. Admittedly it is an
obscure, marginal, little-known and little-used border case, but it
_is_ documented that constructors can be called on existing objects.
In fact, that is what happens during object construction: a new instance
is allocated and zeroed (in one step), and the constructor method called
on the new instance. You can call a constructor as a class method, but
Self will be the instance... won't it?

Groetjes,
Maarten Wiltink

Jamie < XXXX@XXXXX.COM > wrote in



<snip>

Thanks for the advice - I've already replied to Tom with the necessary 
changes, and I've indeed added constructor/destructor code.

Am I correct in assuming that a newly created, empty TObjectList still 
takes up memory? If so, then I prefer to set the TObjectList to nil, 
rather than creating a new one.
 

Indeed - an oversight on my part. In the AddDoubles procedure I had it 
the right way round. Thanks for pointing this out!


The good news is that I've changed the call to IntToStr(dbls.count), the 
bad news is that I still get the error :(

Thanks,

Ikke

@mid.individual.net:




Thanks for the information - however, I'm rather new at Delphi. Would you 
care to elaborate a little? I'm afraid that I can't seem to figure out a 
solution from this advice...

Thanks,

Ikke

Ikke < XXXX@XXXXX.COM > wrote in



<snip>
<snip>

Never mind this one - I figured out that I need to call "Inherited 
Create;" .

Ikke

I see ;-)

Something seems to be wrong with your code. Either somebody overwrites 
the container object, or the object is destroyed for some reason, making 
the reference to dbls s{*filter*}and freeing the memory for further reuse.

DoDi