[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::debug

Title:DEBUG
Notice:Updated locations for reporting QARs -- see note 834.1
Moderator:LOWFAT::DIETER
Created:Fri Jan 24 1986
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1868
Total number of notes:8200

1838.0. "Heap Analyzer missing free() calls?" by CADSYS::LARRICK () Fri Feb 14 1997 12:23

OpenVMS Alpha DEBUG Version V7.1-000.
(compiler DEC C V5.2-003 on OpenVMS Alpha V7.1)

I am attempting to use the Heap Analyzer to find memory leaks in my
application.  I have done so successfully in the past, with VAX versions of HA.
Thus, I was quite surprised to see a large number of "new" memory leaks.

So I wrote a test program (foo.c, appended below) that just allocates and
deallocates memory.  It shows that Heap Analyzer is missing some number of C
RTL free() calls.  (By "missing", I mean that the display still shows the
blocks as allocated.)

Interestingly, if I remove the section of code dealing with VM zones, all is
well.  But note that all the VM zone calls are *after* the CRTL calls, so this
is quite puzzling.

Is this a known problem with Heap Analyzer?  Am I doing something stupid?  

Thanks,
-Doug

/* to compile and link:
  cc/noopt/debug foo
  link/debug foo
*/
#include <stdlib.h>
#include <stdio.h>
#include <lib$routines.h>
#include <libvmdef.h>

#define USEZONE

#define SUCCESS(st) ((st & 1) == 1)

#define RETURN_NOT_SUCCESS(st) {if (!SUCCESS(st)) return st;}

#define NEW_Z(z, sz, p) {				\
  unsigned int status;					\
  status = lib$get_vm(&(sz), (void **)&(p), &(z));	\
  RETURN_NOT_SUCCESS(status);				\
}
#define CREATE_ZONE(z, alg, algarg) {					\
  unsigned int status;							\
  unsigned int flg = LIB$M_VM_GET_FILL0 | LIB$M_VM_BOUNDARY_TAGS;	\
  status = lib$create_vm_zone(&z, &alg, &algarg, &flg, NULL, NULL,	\
			      NULL, NULL, NULL, NULL, NULL, NULL,	\
			      NULL);					\
  RETURN_NOT_SUCCESS(status);						\
}

#define DISPOSEZ(p, z) {			\
  unsigned int status;				\
  status = lib$free_vm(NULL, &(p), &(z));	\
  RETURN_NOT_SUCCESS(status);			\
  (p) = NULL;					\
}

#define FREE_ZONE(z) {				\
  unsigned int status;				\
  status = lib$delete_vm_zone(&(z));		\
  RETURN_NOT_SUCCESS(status);			\
  (z) = NULL;					\
}

#define NUM_ALLOC 100
int main(void)
{
  int i;
  int *ptr;
  int **arr;
  int zone_alg;
  unsigned int zone_arg;
  void * zone;

  /* Simple alloc */
  for (i=0; i < NUM_ALLOC; i++) {
    ptr = (int *)malloc(sizeof(int));
    free(ptr);
  }

  /* Alloc, store into array */
  arr = (int **)malloc(sizeof(int *) * NUM_ALLOC);
  for (i=0; i < NUM_ALLOC; i++) {
    ptr = (int *)malloc(sizeof(int));
    arr[i] = ptr;
  }
  for (i=0; i < NUM_ALLOC; i++) {
    free(arr[i]);
  }
  free(arr);
#ifdef USEZONE
  /* Zone alloc */
  zone_alg = LIB$K_VM_FIRST_FIT;
  zone_arg = 0; /* No argument for first fit */
  CREATE_ZONE(zone, zone_alg, zone_arg);

  /* Repeat test above, individual deallocates */
  NEW_Z(zone, sizeof(int *) * NUM_ALLOC, arr);
  for (i=0; i < NUM_ALLOC; i++) {
    NEW_Z(zone, sizeof(int), ptr);
    arr[i] = ptr;
  }
  for (i=0; i < NUM_ALLOC; i++) {
    DISPOSEZ(arr[i], zone); 
  }
  lib$free_vm(NULL, &(arr), &zone);
  /* DISPOSEZ(arr, zone);  */

  /* Repeat test above, free entire zone */
  NEW_Z(zone, sizeof(int *) * NUM_ALLOC, arr);
  for (i=0; i < NUM_ALLOC; i++) {
    NEW_Z(zone, sizeof(int), ptr);
    arr[i] = ptr;
  }
  FREE_ZONE(zone);
#endif
  return EXIT_SUCCESS;
}
T.RTitleUserPersonal
Name
DateLines
1838.1SSPADE::HIDERPaul Hider, DTN 381-2251Wed Feb 19 1997 14:3812
    You have indeed come across a bug in the Heap Analyzer.  I had to
    step through it with the debugger to find it.
    
    The problem is that the Heap Analyzer is essentially a 32-bit animal
    living in a 64-bit world.  It does try to be 64-bit address aware,
    and this is where the problem is.  It picks up some garbage as part
    of an address.
    
    We are currently working on enhancements to the Heap Analyzer to make
    it properly 64-bit aware, so this will be fixed as part of this work.
    
    _Paul
1838.2CADSYS::LARRICKWed Feb 19 1997 15:033
Thanks for the quick reply.  I'll be looking forward to a fixed future version.

-Doug