EInvalidPointer- "Invalid Pointer Operation" - NULL pointer ???
Indranil Bandyopadhyay
Can someone help me, please.
When I exit my Delphi application I get this error:
EInvalidPointer, 'Invalid pointer
operation'
The mystery gets deeper.
a.) If I copy the executable to another machine - I do not get this
error !
b.) I reinstalled BDE onto both machines to see it if makes a difference
- No difference.
c.) I turned on/off all the optimizations/boolean evaluations to see if
it makes a difference - None.
I can debug the MainForm.OnClose.... to the last 'end;' and then I get
the error. I even though of putting
a try ... except on EInvalidPointer ....do nothing... to avoid the error
message. But I cannot even figure out
where to put this handler.
Does anyone know how to find a NULL pointer in Delphi.
Remember... In Borland CPP we do set something like (Char *) 0, 4 in
our watch window
and step though each line to see if we write over our NULL pointer.
Any equivalents for Delphi for a NIL pointer ??
All ideas appreciated.
ib
iban...@dmtn.com
Jeff Rafter
what are both of the machines you tested... video drivers or comctls.dll
versions?)
Good Luck,
Jeff Rafter, Realsoft Development
http://www.realsoftdev.com
jeffr...@earthlink.net
Andrew Jackson
other DLLs that you are using, to the point where the area of memory that
holds your functions gets corrupted so you code executes abnormally.
Usually very difficult to trace the problem unless you know what you did to
your code to first make the problem appear.
Try running your app through a 3rd party debugging tools such as Numega
Boundschecker or MemProof
http://www.nidlink.com/~astoyanov/index.htm
These can spot memory overruns etc.
Indranil Bandyopadhyay wrote in message <35E07FCF...@dmtn.com>...
Indranil Bandyopadhyay
Jeff Rafter wrote:
> What kind of machine and what version of Delphi are you using? (Actually
> what are both of the machines you tested... video drivers or comctls.dll
> versions?)
Jeff,
Both machines are identical (NT clients P166-same video and network cards).
They were bought at the same time as network clients. I am using Delphi 3.0.
I ran Boundschecker and found the messages from boundschecker too
overwhelming to be of any use.
I had more success with MemProof and it pointed to the last 'end;' in my
project.dpr file and reported:
{$R *.RES}
begin
Application.Initialize;
Application.Title := 'Lot Management System V4.00';
Application.CreateForm(TMainForm, MainForm);
Application.CreateForm(TEntryForm, EntryForm);
Application.CreateForm(TTransferForm, TransferForm);
Application.CreateForm(TNewPartNoForm, NewPartNoForm);
Application.CreateForm(TDM, DM);
Application.Run;
end. <----- DestroyCursor(5174): Unknown Win32 Error
My 'stack trace' shows:
$0002E90C TScreen.GetFormCount in Forms (0)
$000027BB @TryFinallyExit in System (0)
$000029DA @Halt0 in System (0)
$00018344 initialization in Lms400.dpr (31)
$00018344
$000181F6
I am not really good at reading stack traces and memory dumps yet. Hope
someone will see something and guide me in the right direction.
All I know is that when my application exists. It calls
DestroyCursor(xxxx);
I do not do any cursor manipulation in my application which is a simple
database application.
The only thing I plan to do next is to begin commenting out my code with the
last changes first and see where the problem disappears.
Also I noticed when I 'build' for the debuggers some parts {structure
initializations} of my code cause execptions. Looks like I have something
even more dangerous living in my code.
All help appreciated.
Atanas Stoyanov
>end. <----- DestroyCursor(5174): Unknown Win32 Error
>
>My 'stack trace' shows:
>
>$0002E90C TScreen.GetFormCount in Forms (0)
>$000027BB @TryFinallyExit in System (0)
>$000029DA @Halt0 in System (0)
>$00018344 initialization in Lms400.dpr (31)
>$00018344
>$000181F6
I am afraid that this output from MemProof just shows a standard VCL error
(the VCL code attempts to destroy a cursor that it did not create). This
error is "benign" {well, almost} and is certainly not the cause of your
trouble.
Also from your call stack, it seems that you did not inlude the VCL in your
project build. Including the VCL source code will give you much more
information as or the origin of oyur error.What you can do is fropm
Project/Options/Directries and in the Search Path edit box, type
c:\delphi3\source\vcl; {where c:\delphi3 is your Delphi directory}.
There are two ways that MemProof could be usefull for you to track such an
error (try one of the two first):
*) You can do the following : From MemProof select Options/Trace Stack on
Exception. Run your program and try to reproduce the EInvalidPointer error.
When the error occurs, if you open the debug window in MemProof (View/Debug
Output Window or Ctrl+D), MemProof will show you the call stack of how the
exception occured. Hopefully this willlead youto the origin of the
EInvalidPointer exception in your source code.
*) You can set the Options/Check for Memory Overruns and Options/Error on
invalid Free to true (checked). Run you program and look if anymore errors
(items with the stop sign) are generated than without those options.
Before using you programin MemProof , just a reminder :
*Include the DELPHI\SLIB directory as part of your search path.
*Compile with Stack frames.
*Include the VCL source directory in your Project/Directories options
If you have any troubles interpreting the output of MemProof or other
questions, please do not hesitate to contact me via private e-mail.
Atanas
MemPoof's Home :
http://www.nidlink.com/~astoyanov/index.htm
Indranil Bandyopadhyay
Thank you for all your helpful tips on using MemProof, I have tried to detect
my bug but have not been successful. One reason is that it does not occur
everytime at the same place. It appears to move around and
disable my code at different places. I will try again tomorrow and post my
findings here. Hope you can help.
MemProof It truly is a superb product. I have some rediculously simple
questions for you. Sorry I am not very good at understanding how debuggers
work.
My questions are what can I understand when I see the 'Live Pointer' or
'Virtual Memory' icon and source code window is highlighted with a line ?
Thank you again for your quick reply
ib
Jeff Rafter
>everytime at the same place. It appears to move around and
>disable my code at different places.
It sounds more and more like a stack error... check the size of your stack.
One more guess... are you using a Codebase database? (Or what database
engine / version?)
Jeff
Atanas Stoyanov
First, thanks for your nice words about MemProof
>My questions are what can I understand when I see the 'Live Pointer' or
>'Virtual Memory' icon and source code window is highlighted with a line ?
Live Pointers :
Live Pointers are your most important leaks. You should always try to fix
those memory leaks first. They are native Delphi memory that you allocated
by either creating a class, a huge string, using functions like GetMem and
New etc.
In this area MemProof can help with more info when you have the
Options/Translate pointers enabled (the default). While running your
program, if you double click on the live pointers entry, MemProof will
display a list of all the live pointers currently allocated in your program
and in the Name column you migh see their class names like :
TMemo <class> - this indicates a TMemo class that is in memory.
Also MemProof will show long strings like that :
November <string> - This indicates that you (or the VCL) have allocated
memoryu for a long string and the contetnt of this string is 'November'.
This functionality of MemProof is available only while your program is
running, because those strings are allocated in the address space of your
program. So if you want the final leaks report to include those meaningfull
names, just before exiting your program, select for once the View/Snapshot
of all resources (you can immediatelly after that close this view). This
will make MemProof to translate the Delphi pointers to strings and might
help you determine what are your exact leaks - it's often helpfull to know
that you have a specific class name that is not being freed.
Virtual Memory :
The virtual memory counters are reflecting the amount of memory that your
application is requesting from the operating system (Windows) via WinAPI
functions like VirtualAlloc etc.
Even if you do not use the VirtualAlloc functions yourself, behind the
scenes the Delphi Memory manager is using them. In fact the Delphi Memory
Manager is allocating chunks of 16 K memory from the OS and then is
distributing those 16k regions as 'live pointers' requests to your
application. So if you forget to free a live pointer, the delphi memory
manager will not free the corresponding 16K virtual memory region. You can
see that this way a small pointer of a couple of bytes might cause a real
memory leak of 16 K bytes to the operating system.
Even tough it is very instructif to see how the Delphi Memory Manager is
allocating its memory from the operating system, if you are not using
VirtualAlloc functions yourself, you might disregard this entry.
Always keep in mind that if you solve the Live Pointers leaks in your
application, the Virtual Memory leaks will be solved as well (except a leak
of 4096 bytes that is always there because forms.pas forgets to free 4K of
memory once for every application).
Thanks
Atanas
Indranil Bandyopadhyay
I understand a lot more about MemProof now. I like the fact MemProof can show
me what resources are allocated at runtime (Cntrl-D). I think I understand how
debuggers work better now. MemProof keeps track of all the allocations and
deallocations and on termination tells me what is 'not' deallocated. Therein
should lie my problem.
I tried to make my application fail with exceptions today but could not.
However that did not stop me from learning more about MemProof and my
application. I created a simple delphi form added more components and methods
to it just to see what MemProof reported.
The live pointers reported when my application terminates are:
[Area Item Current# Peak# CurrentSize Peak
Size]
-----------------------------------------------------------------------------
A. Pointers Live Pointer 4 1771
118 104986
B. Memory Virtual Memory 1 8 16384
118784
A. Live Pointer Errors:
-----------------------
i.)
TCaptureFields <class>
O := TCaptureFields.Create;
My guess is that I am not deallocating memory here. Using Delphi IDE I had at
one time got an exception
at the constructor ? I have used this piece of code for about a year now but I
guess it is a source of a memory
leak.
{ CaptureFields Object - constructor
}
constructor TCaptureFields.Create;
begin <---------- BCB
DisplaySeq :=0;
DisplayLbl :='';
FldAddEdit :=False;
end;
{Create}
Defined as ....., Hmmm.... I don't see any memory overruns or anything.
type
TCaptureFields = class
DisplaySeq : SmallInt;
DisplayLbl : string[15];
FldAddEdit : Boolean;
constructor Create;
end; // CaptureFields
Question: I changed to SmallInt->Integers and String[15] to Strings (checking
for overruns) but it made no difference. I may have to step throught the code
to see if I leave any residue. By the way bounds checker
bombs with an 'access exception' in the intialization code marked (BCB) above.
The other two Live Pointer Errors are also interesting.
ii)
in function UnLogApplication: Boolean
FindKey([WorkstationNum]); <--------- Line 712 Live Pointer Error
Three Stack entries, two the same number
Stack trace
Stack trace
No Stack trace
Stack Display in MemProof
StrPas(0)
TAdsTable.GetIndexFieldNames in AdsTable (0)
TAdsTable.SetKeyFields in AdsTable (0)
TAdsTable.FindKey in AdsTable (0)
This FindKey is calling TAdsTable.Findkey of the Advantage {extended systems
database engine}. This is supposed to be the same as the delphi FindKey.
I am using FindKey only once in my code. I will change it to 'AdsSeek' and see
if it makes any difference tomorrow.
Question: Is it possible that I am getting an error because I am not checking
the Boolean return value from FindKey?
iii)
VirtualAlloc(xxxxxx) Virtual Memory
try
DM.ShippedFindTable.Active:=True; <------------------Virtual Alloc
Problem
except on EDataBaseError do
Memo2.Lines.Add('Cannot Open ShippedFindTable'+
DM.ShippedFindTable.DatabaseName+' '+
DM.ShippedFindTable.TableName );
end;
Question: Is this not odd ? I am opening six database one after another yet it
points to this line everytime reporting Virtual Allocation Error. Do you have
any ideas ?
I know I am asking you a lot of information and many of my questions are
probably very silly. I realize that you are extremely busy and I want to thank
you again for helping me to debug this project.
Do you know any URL's or books that I should read so that I can debug much
better with MemProof ?
I really really appreciate all your comments. :) Thanks again for MemProof !!
Yours Sincerely,
IB
Indranil Bandyopadhyay
> >my bug but have not been successful. One reason is that it does not occur
> >everytime at the same place. It appears to move around and
> >disable my code at different places.
> It sounds more and more like a stack error... check the size of your stack.
Min Stack $00004000Max Stack $00100000
Image Base $00400000
> One more guess... are you using a Codebase database? (Or what database
> engine / version?)
>
You could be right on the money. I changed over to Advantage Database from
Borland Paradox.Just replaced the TTable -> TAdsTable.
If I am reading it right MemProof points to TAdsTable.FindKey as a Virtual
memory hog.
and
i.]
FindKey([WorkstationNum]); <------------- LivePonter Problem.
ii.]
try
DM.ShippedFindTable.Active:=True; <--------------Virtual Alloc Problem
except on EDataBaseError do
Memo2.Lines.Add('Cannot Open ShippedFindTable'+
DM.ShippedFindTable.DatabaseName+' '+
DM.ShippedFindTable.TableName );
end;
It could be the product or it could be bad programming practice on my part.
What was your guess with codebase?
I am looking into every option possible to fix the EInvalidPointer Exception. I
have never got it under MemProof or BoundChecker. Although BoundsChecker
'itself' gave an exception error
" Exception EInvalidPointer in Module BCCORE.DLL at 0005D62C.
Invalid pointer operation. "
Then it just shut my machine down!!
I guess that my code must be too bad for bondschecker to resolve <g>.
Have to hand it to MemProof though, although I am having a hard time
interpreting the results {my own inadequacy, it has stuck along this far.}
All suggestions accepted.
Thanks for your help,
IBI
Indranil Bandyopadhyay
MemProof Rocks !
With the additional information about the vcl that you provided I thought I
would
add some more information.
The problem is releasing a TList Object at location (1) below.
The EInvalidPointer occurs only once when the application shuts down. At this
time 'NewCapacity' is a huge number but it cannot be since the Stack Trace is
TList.Clear.?? I will verify this again tomorrow.
I will try to locate which TList component it is trying to release and work a
fix around this.
I want to thank you for being there to help me out.
Call Stack is:
------------
TList.Destroy
TList.Clear
TList.Destroy
TComponent.DestroyComponents
TComponent.Destroy
TDataModule.Destroy
TComponent.DestroyComponents
DoneApplication
Lms400
Watch List
-----------
FList: $37F17D4
NewCapacity:0
SizeOf(Pointer):4
FCapacity:4
..\source\vcl\Class.Pas - called from forms.pas below
-----------------------
procedure TList.SetCapacity(NewCapacity: Integer);
begin
if (NewCapacity < FCount) or (NewCapacity > MaxListSize) then
Error(SListCapacityError, NewCapacity);
if NewCapacity <> FCapacity then
begin
ReallocMem(FList, NewCapacity * SizeOf(Pointer)); <---- (1)
FCapacity := NewCapacity;
end;
end;
Exception EInvalidPointer in Module... Invalid Pointer Operation
Called from ..\vcl\Forms.pas
-----------------------------
procedure DoneApplication;
begin
with Application do
begin
if Handle <> 0 then ShowOwnedPopups(Handle, False);
ShowHint := False;
Destroying;
DestroyComponents;
end;
end;
Jeff Rafter
I don't really understand the results you are getting from memproof as I
have never used an application of that sort, but if the problem seems to
correspond to the database change-over I would be thinking the problem lays
down that road.
Have you tried asking if this is a common problem through their tech
support? And is it possible to revert to another database engine
temporarily to test if that is infact the problem...
I was looking at your earlier post and thought "I bet the databases
<internal cursor> is causing the problem" Then I thought... "but why would
the two machines be different?" and then thought this: "Are the results the
same if you run the application outside of delphi? (do you still get the
error on both machines) and what dlls (or dpls) if any are being deployed
with your database engine."
I recently screwed up my freinds computer by installing a program (that I
wrote) to his machine to "show off." Instead of praise and accolades my
install overwrote a system critical dll... oops. He couldn't get anything
to work right until we figured it out.
Good luck,
Atanas Stoyanov
>I am removing all the 'live pointers' in my code and hoping it will remove
the
>problems that I began this discussion with.
Yes, this sounds like a good approach.
>I have two simple question about MemProof.
>
>What is the Kind=Event it has an 'atomic-nuclear' icon.
>MemProof says:
>
>CreateEvent(00000000, -1, -1, 0); at my code:
>OverlappedCommEvent.hEvent := CreateEvent(nil, True, True, nil);
The 'atomic-nuclear' icon are resources allocated from the Windows Kernel
DLL (kernel32.dll).
In MemProof, the Kind = Event are events (in the WinAPI sense of the term)
objects. If you forget to free such objects, they result in 'resource'
leaks.
You create such objects with the
CreateEvent(..) WinAPI
and you free such objects with the
CloseHandle (...) WinAPI
>My guess is that it cannot create that event.
Not really - If it cannot create that event, MemProof would display an error
entry (Kind = Error - with the stop sign icon). In your case (Kind = Event),
MemProof shows that the event has been successfully created and will have to
be freed.
If the event is part of the final leaks reports, then you forgot to free the
event handle and should add a line like
CloseHandle(OverlappedCommEvent.hEvent).
Hope this clears it
Atanas