Tim

I'm getting a slew of these

--------------------------------2007/8/15 13:19:53--------------------------------
A memory block has been leaked. The size is: 1036

Stack trace of when this block was allocated (return addresses):
326322 [@Borlndmm@SysAllocMem$qqri]
402E16 [System][AllocMem]
651404 [dbisamlb][ResizeBuffer]
6640BF [dbisamlb][TExpToken.ResizeValueBuffer]
664022 [dbisamlb][TExpToken.Create]
66523F [dbisamlb][TExpressionParser.GetNewExpToken]
669F56 [dbisamlb][TExpressionParser.ParseExpression8]
66AA3F [dbisamlb][TExpressionParser.ParseExpression7]
66AA8D [dbisamlb][TExpressionParser.ParseExpression6]

The block is currently used for an object of class: Unknown

Roy Lambert

Roy,

<< I'm getting a slew of these >>

Could you give me a little more information on the context of where you're
seeing these ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Could you give me a little more information on the context of where you're
>seeing these ?

Not too much. I've enabled FastMM leak tracing and when I close down the app I'm developing I get a leak reported. I'm clobbering those I can trace but these I have no idea about. I haven't yet been able to track down a single set of actions that produce the leaks, about the best I can guess is it involves TMS controls, DBISAM tables & queries with and without parameters.

XP Home SP2, D2006 fully patched, DBISAM V4.25b5 working in the IDE.

That about sums up the "intelligence" so far.

I know its not much use and if I manage to figure out the exact circumstances I'll let you know - but don't hold your breath

Roy Lambert wrote:

> Tim
>
>
>
>>Could you give me a little more information on the context of where you're
>>seeing these ?
>
>
> Not too much. I've enabled FastMM leak tracing and when I close down the app I'm developing I get a leak reported. I'm clobbering those I can trace but these I have no idea about. I haven't yet been able to track down a single set of actions that produce the leaks, about the best I can guess is it involves TMS controls, DBISAM tables & queries with and without parameters.
>
> XP Home SP2, D2006 fully patched, DBISAM V4.25b5 working in the IDE.
>
> That about sums up the "intelligence" so far.
>
> I know its not much use and if I manage to figure out the exact circumstances I'll let you know - but don't hold your breath
>

Roy,
   What happens if you just create the datamodule and then exit without
doing anything else? Does the error show up then? If yes, then it is
somewhere in your initialization so comment out sections of code until
it goes away. If there is no error when the datamodule is created, then
go a little deeper into the program until the error appears and start
commenting out code or just put {$IFDEF MEMDEBUG}EXIT;{$ENDIF} in the
start of your routines.

Dave

Roy Lambert wrote:

> Stack trace of when this block was allocated (return addresses):
> 326322 [@Borlndmm@SysAllocMem$qqri]
> 402E16 [System][AllocMem]
> 651404 [dbisamlb][ResizeBuffer]
> 6640BF [dbisamlb][TExpToken.ResizeValueBuffer]
> 664022 [dbisamlb][TExpToken.Create]
> 66523F [dbisamlb][TExpressionParser.GetNewExpToken]
> 669F56 [dbisamlb][TExpressionParser.ParseExpression8]
> 66AA3F [dbisamlb][TExpressionParser.ParseExpression7]
> 66AA8D [dbisamlb][TExpressionParser.ParseExpression6]

By default fastmm only gives you the last 9 steps of the stack. If you
want to see what triggers this leak you have to increase the stack
trace depth size. In fastmm4.pas search for:

StackTraceDepth = 9;

and change it to something like 50. Things will get considerably slower
but you get a lot more information.

Jan Derk

Dave


Nope. The app is MDI and so far I'm seeing variants of this report from a couple of the child forms, and only after doing "something". I'm still trying to figure out just what the something is.


Roy Lambert

Jan


Thanks - I'll try that

Roy Lambert

Did you ever find anything on these leaks? I ask as I'm trying to verify
my app, and it is leaking a lot on opening tables according to AQTime
(latest version).

What I don't understand is how I can have more than one of these given the
code closes the query first. I could understand leaking one if I killed
the thread before closing or something, but that doesn't happen - I have
more than one of these in my leaks. It is possible that AQTime 5 is
getting it wrong of course.

I'll be continuing to look at this, so will report back. D7, DBISAM 4.22
Build 4 in case it is relevant. Code and stack below.

/Matthew Jones/

procedure TFTPUploadThread.PrepareFileQuery;
var
   szSQL : string;
   nQueueID : Integer;
begin
   m_xFileQuery.Close;

   nQueueID := m_xWorkQuery.FieldByName('cqItemID').AsInteger;
   szSQL := 'SELECT fsQueueID, fsLinkReference, fsBlob ';
   szSQL := szSQL + 'FROM FileStore ';
   szSQL := szSQL + 'WHERE (fsQueueID = ' + IntToStr(nQueueID) + ')
';

   m_xFileQuery.SQL.Text := szSQL;
   m_xFileQuery.Open;
end;


Routine Name   Class Name   Source Line   Source File
NewCommit      0   
TryHarder      0   
SysGetMem      0   
GetMem      0   
AllocMem      0   
ResizeBuffer      0   
TBufferedFile::ResizeReadBuffer   TBufferedFile   0   
TIndexFile::ReadIndexes   TIndexFile   0   
TIndexFile::OpenFile   TIndexFile   0   
TDataTable::OpenTable   TDataTable   0   
TDataDirectory::OpenDataTable   TDataDirectory   0   
TDataCursor::OpenCursor   TDataCursor   0   
TDataQuery::CreateResultTable   TDataQuery   0   
TDataQuery::PrepareSelectQuery   TDataQuery   0   
TDataQuery::PrepareQuery   TDataQuery   0   
TQueryStatement::PrepareStatement   TQueryStatement   0   
TDBISAMQuery::GetStatementHandle   TDBISAMQuery   0   
TDBISAMQuery::PrepareSQL   TDBISAMQuery   0   
TDBISAMQuery::SetPrepared   TDBISAMQuery   0   
TDBISAMQuery::GetQueryCursor   TDBISAMQuery   0   
TDBISAMQuery::CreateCursor   TDBISAMQuery   0   
TDBISAMQuery::CreateHandle   TDBISAMQuery   0   
TDBISAMDataSet::OpenCursor   TDBISAMDataSet   0   
TDBISAMDBDataSet::OpenCursor   TDBISAMDBDataSet   0   
TDataSet::SetActive   TDataSet   0   
TDataSet::Open   TDataSet   0   
TFTPUploadThread::PrepareFileQuery   TFTPUploadThread   270   
uSFTPThread.pas
TFTPUploadThread::RunFTPStateMachine   TFTPUploadThread   329   
uSFTPThread.pas
TFTPUploadThread::Execute   TFTPUploadThread   154   
uSFTPThread.pas

Matthew


If you're asking me the answer is no. I had about a month where I couldn't do any development whilst my notebooks screen was being replaced then I've switched from MDI to embedded forms on a pagecontrol after much time spent playing with frames (yuch) and finishing TMS'ing the app. Currently rewriting my lookup components to the TMS look whilst waiting for 1.06.

Roy Lambert

Matt,

<< What I don't understand is how I can have more than one of these given
the code closes the query first. I could understand leaking one if I killed
the thread before closing or something, but that doesn't happen - I have
more than one of these in my leaks. It is possible that AQTime 5 is getting
it wrong of course.

I'll be continuing to look at this, so will report back. D7, DBISAM 4.22
Build 4 in case it is relevant. Code and stack below. >>

Did you try running the application with FastMM4 ?  It will tell you if
there's a leak when the application shuts down.

--
Tim Young
Elevate Software
www.elevatesoft.com