Sign in Join

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

Mailing lists / fpc-devel / 2012-01

issue in heaptrc?

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

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

Martin

I ve been playing around with -gc and I found something suspect in heaptrc

procedure CheckPointer(p : pointer); [public, alias : 'FPC_CHECKPOINTER'];

"p" is a pointer, that should be somewhere *inside* an allocated block of mem

   pp:=loc_info^.heap_mem_root;
   while ppnil do
    begin
      { inside this block ! }
      if
(ptruint(p)>=ptruint(pp)+sizeof(theap_mem_info)+ptruint(extra_info_size)) and

(ptruint(p)<=ptruint(pp)+sizeof(theap_mem_info)+ptruint(extra_info_size)+ptruint(pp^.size)) then

if this loop does not find anything then
   writeln(ptext^,'pointer $',hexstr(p),' does not point to valid memory
block');
   dump_error(p,ptext^);
   runerror(204);
but
   procedure dump_error(p : pheap_mem_info;var ptext : text);

expects a pheap_mem_info, p is not a pheap_mem_info

and that is where it crashes (shortly before dump stack trace :( ) Did I miss something or is there a bug?

Reply by email

Pierre Free Pascal
to Martin

Yes, you are right...

I just committed a fix (together with multi-threaded windows executable support in trunk)
If you have svn trunk, could you check that revision 20181 fixes the problem you report?

Thanks in advance,

Pierre

Show quoted text 23 lines
-----Message d'origine----- De : [mailto:fpc-devel- De la part de Martin Envoyé : jeudi 26 janvier 2012 06:37 À : FPC developers' list Objet : [fpc-devel] issue in heaptrc? I ve been playing around with -gc and I found something suspect in heaptrc procedure CheckPointer(p : pointer); [public, alias : 'FPC_CHECKPOINTER']; "p" is a pointer, that should be somewhere *inside* an allocated block of mem pp:=loc_info^.heap_mem_root; while ppnil do begin { inside this block ! } if (ptruint(p)>=ptruint(pp)+sizeof(theap_mem_info)+ptruint(extra_info_size)) and

(ptruint(p)<=ptruint(pp)+sizeof(theap_mem_info)+ptruint(extra_info_size)+ptr

Show quoted text 22 lines
uint(pp^.size)) then if this loop does not find anything then writeln(ptext^,'pointer $',hexstr(p),' does not point to valid memory block'); dump_error(p,ptext^); runerror(204); but procedure dump_error(p : pheap_mem_info;var ptext : text); expects a pheap_mem_info, p is not a pheap_mem_info and that is where it crashes (shortly before dump stack trace :( ) Did I miss something or is there a bug? _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Martin
to Pierre Free Pascal
Pierre Free Pascal wrote 9 lines
Yes, you are right... I just committed a fix (together with multi-threaded windows executable support in trunk) If you have svn trunk, could you check that revision 20181 fixes the problem you report? Thanks in advance,

It looks right from the code.

it will be a while before I run it. After all it really slows things down...

May I mention 2 ideas?

1)
I observed that at least in my case, I often get repeated checks for the same node.
Caching the last (or last 2) found node(s) (and invalidating the cache in trace_free_mem and trace_realloc_mem), and checking that last node first, did some speed improvement.

2)
This is not that easy to fix
SomeObj.FField
generates code like

move <addr_of_SomeObj>, <register> // e.g. ebp

move <register>, .ax
call checkpointer // chek the objects first byte is in alloc mem

move <offset_of_FField>(<register>) , <foo> // use the field

it is never tested that the field itself is in alloc mem. But not only should the field be in alloc mem, it should be in the same block.

It would require something like
checkpointer(<addr_of_SomeObj>, <offset_ofFField>) and test that the block has a minimum amount of space, after the required address

Reply by email