Memory leaks in standard code

[Paul Richard Thomas]

FX,

> On what code does it segfault? I think *slot == HTAB_DELETED_ENTRY is
> a weird error condition, like freeing twice the same pointer. Or yet
> another problem in my hashtabs :(

HTAB_DELETED_ENTRY  is (PTR)0, so it is perfectly in order.  In fact,
void htab_clear_slot (htab_t htab, PTR *slot) returns with *slot =
HTAB_DELETED_ENTRY, so the free should not be necessary.

> Here, with the patched alloc_comp_code (sorry for forgetting that),
> it reports no memleak (and no segfault either).

Great!  Do some BUILTIN_FREEs check for NULL?
>
> > Several other members of the allocatable component members of the
> > testsuite show memory leaks, however.  Many thanks for a brilliant
> > tool!
>
> Well, we'll have to see if they are really memory leaks or just
> issues with my patch. Many thanks for helping me debug it, by the way!

Not at all - the pleasure is mine because this is something that we
have needed for a long time.  In addition, as I said previously, I
have been meaning for a long time to explore hashtab.c, both for
allocatable components and for F2003 class structures.  A double hash
on the derived type identifier and on the module should serve quite
well in the switch statements, within the class methods.  That is, the
class structure becomes:

struct gfc_class
{
  void *base;  /* Points to the derived type.  */
  htab_t derived;
  htab_t module;
}

Note that this would be used at compile time, since the modules can
broadcast the hashes that they use.  As far as I can tell, F2003 has
no need of vtables or their like.

Cheers

Paul