Is such memory statistics possible?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] Is suchmemorystatisticspossible?

Ludo Brands
Message
 
I'm currently experimenting with a variation of dump_stack in system.inc. The first try skips a lot of the functions found by your initial implementation. Still looking into that.  
 
Got to the cause of this problem. The stack unwind is fine. The backtrace looks like bt in gdb except for the non-stackframe routines (I think I have found a fix for that one too). The problem is in the unit lineinfo. There is a global variable staberr:boolean that, once set, aborts subsequent calls to GetLineInfo. It is set by an error in openstabs and there is no way to reset it. Limiting the traced addresses to the ones inside the main application solves that one but limits obviously the output (no runtime loaded libraries, etc).
 
Attached the patch for the stack unwind (without non-stackframe routines). Note that all assembler is gone!
 
Ludo
 
 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

uProcMemStat.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] Is suchmemorystatisticspossible?

Max Vlasov
On Mon, Aug 22, 2011 at 5:29 PM, Ludo Brands <[hidden email]> wrote:
>

>
> Attached the patch for the stack unwind (without non-stackframe routines).
> Note that all assembler is gone!
>


Ludo, the patch looks very promising, I just found one problem. I have
a test fragment in my form (in a simple simplest application)

procedure TForm1.FormCreate(Sender: TObject);
var
  a: integer;
begin
  a:=1;
  GetMem(fTest, 1024*1024);
  GetMem(fTest2, 1024*1024);
end;

The previous version of the monitor showed TFORM1_FORMCREATE as a
source of 2M, currently there is no such symbol in the list. The frame
is definitely created so there should be no problem with the absence
of one.

Max
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

RE : RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] Issuchmemorystatisticspossible?

Ludo Brands
>

> Ludo, the patch looks very promising, I just found one
> problem. I have a test fragment in my form (in a simple
> simplest application)
>
> procedure TForm1.FormCreate(Sender: TObject);
> var
>   a: integer;
> begin
>   a:=1;
>   GetMem(fTest, 1024*1024);
>   GetMem(fTest2, 1024*1024);
> end;
>
> The previous version of the monitor showed TFORM1_FORMCREATE
> as a source of 2M, currently there is no such symbol in the
> list. The frame is definitely created so there should be no
> problem with the absence of one.
>
The problem is a missing stack frame. The caller (TFORM1_FORMCREATE) has a
stackframe but the callee (GetMem) doesn't.

In other words: the address below the frame is the address of the caller. To
find the caller, the callee has to have a stackframe.

Attached a patch for missing stack frames. This doesn't solve all cases but
most. The const MAXFAILS could be made higher but that is again running the
risk of getting false positives. The reason for having maxfails is that a
lot of valid addresses are outside the main program area. Your testcase is
an example.

Ludo

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

uProcMemStat.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RE : RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] Issuchmemorystatisticspossible?

Max Vlasov
On Mon, Aug 22, 2011 at 6:48 PM, Ludo Brands <[hidden email]> wrote:

>>
>> Ludo, the patch looks very promising, I just found one
>> problem. I have a test fragment in my form (in a simple
>> simplest application)
>>
>> procedure TForm1.FormCreate(Sender: TObject);
>> var
>>   a: integer;
>> begin
>>   a:=1;
>>   GetMem(fTest, 1024*1024);
>>   GetMem(fTest2, 1024*1024);
>> end;
>>
>
> The problem is a missing stack frame. The caller (TFORM1_FORMCREATE) has a
> stackframe but the callee (GetMem) doesn't.
>
> In other words: the address below the frame is the address of the caller. To
> find the caller, the callee has to have a stackframe.
>
> Attached a patch for missing stack frames. This doesn't solve all cases but
> most. The const MAXFAILS could be made higher but that is again running the
> risk of getting false positives. The reason for having maxfails is that a
> lot of valid addresses are outside the main program area. Your testcase is
> an example.
>

I see, it makes sense. And this temporal look up with maxfails looks
like decent workaround.

There are some things we discussed to fix and improve. Ludo, Isn't it
better to move the following discussion to the bugtracker inside a new
"feature request" topic. I just suppose there are few readers here
that follow and interested in this discussion :) (CMIIW)

Max
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12