memory leaks in ACEDB

Henry J. Cobb hcobb at fly2.berkeley.edu
Wed Apr 6 17:18:50 EST 1994

	Had a few problems with the new file locking write access under
purify, so I got the Sentinel program demo (from mike.simon at aib.com) and
ran that.

	I added a comment to an item in the database and it complained
about a leak of 510 bytes at wbs/bstree.c at line 341:

	 bs->bt->cp = messalloc(strlen(BSbuffer)+1);

	And also:

0x19EC18    M messalloc()     [/home/hgc/data14 malloc(532)         1         12
              uArrayCreate()  [/home/hgc/data14/Drosophila/flydb-v3.1/wfree/arraysub.c:56]
              arrayCopy()     [/home/hgc/data14/Drosophila/flydb-v3.1/wfree/arraysub.c:164]
              makePaths()     [/home/hgc/data14/Drosophila/flydb-v3.1/wbs/bssubs.c:1382]
              makePaths()     [/home/hgc/data14/Drosophila/flydb-v3.1/wbs/bssubs.c:1365]
              makePaths()     [/home/hgc/data14/Drosophila/flydb-v3.1/wbs/bssubs.c:1365]
              makePaths()     [/home/hgc/data14/Drosophila/flydb-v3.1/wbs/bssubs.c:1365]
              bsMakePaths()   [/home/hgc/data14/Drosophila/flydb-v3.1/wbs/bssubs.c:1331]
              objDecorate()   [/home/hgc/data14/Drosophila/flydb-v3.1/wbs/bssubs.c:166]
              bsUpdate()      [/home/hgc/data14/Drosophila/flydb-v3.1/wbs/bssubs.c:215]

	Which I suspect that:bssubs.c: line 1382

  if (bsIsTag(bs) && bs->key != _ANY &&
      !assInsert (ass,(void *)bs->key,arrayCopy(workPath)))

	forgets to release the copy of the array.

	Also lexsubs.c: line 899

  LexHashTable[classe] = arrayCreate(1<<n, KEY) ;

	the Table seems never to get deallocated. (In fact the entire set
of Lexi structures seems to just get abandoned at program end, is this safe
on the Mac?)

	In disksubs.c:diskBATread(), the batArray is simply abandoned at
program end.

	Picksubs.c:pickGetClassProperties(), classAppearance is abandoned.

	queryexe.c:checkParentheses(), bra is left behind.

	ditto for picksubs.c:pickGetDisplayTypes(), dtStack.

	and picksubs.c:pickInit(), pickStack.

	And it goes on and on for page after page (the vast majority being
in Xt's own mistakes).

	I think it's fairly clear that people aren't very good at
determining the proper lifetimes for objects.  This is handled for the
programmer in C++ by having the objects clean themselves up when they fall
out of scope, but it has to be done manually in C.

	I suggest that each of the "*Init" functions in wormInit() have a
matching "*Release" function, to be called in reverse order.

	Henry J. Cobb hcobb at fly2.berkeley.edu, SFB Tyrant-for-life
	A "Bjorn again" programmer.

More information about the Acedb mailing list

Send comments to us at biosci-help [At] net.bio.net