Re: Freeing memory used by sqlda in ESQL/C

>From: vic@teal.csn.org (Victor E. Schoenberg) >Subject: Freeing memory used by sqlda in ESQL/C >Date: Thu, 17 Feb 1994 18:57:19 GMT >X-Informix-List-Id: <news.5588> > >When using an sqlda structure in Informix ESQL/C, what is the >proper way to free the memory after use? > >We are using a DESCRIBE statement, which causes Informix to >create an sqlda struct with a pointer to an sqlvar_struct array. > >We allocate a buffer and assign sqldata to point to it; after >use, we free the buffer. This much is indisputably correct -- if you allocated it, you free it. >Does Informix free the rest of the data, such as the sqlind, >sqlname, etc., or should we? Does Informix free the sqlvar_struct >array? The sqlda? What is the right way to prevent a memory leak? This gets trickier... First of all, you are responsible for allocating pointers to the sqlind stuff; ESQL/C doesn't assign anything there. Therefore, you are responsible for freeing it, if you used allocated memory. You might not have done for indicator variables. I tend to use pointers to 2 short integers, one containing 0, t'other -1. Another piece of good news: the memory in the SQLDA structure is allocated in a single chunk which has enough space for the sqlda structure, the associated array of sqlvar_structs, and any names associated with the structure. This can be demonstrated easily enough with a debugging memory allocation system. Now the bad news: the sqlname and related stuff is is handled by ESQL/C -- IF it handles the sqlda space at all. I don't have the wherewithal to prove my point immediately, but I believe that some versions of ESQL/C do release the previously allocated sqlda structures for you when you next describe into the same statement ID -- and never release it if you don't re-use the statement ID -- and woe betide your memory allocator if you try to do the release for it. On the other hand, I believe that other versions of ESQL/C don't release the previously allocated sqlda structure, even when the statement is re-described. Which version is which, you say? There I get stuck -- my memory is failing or something. I think, but haven't time to verify, that 4.1x and 5.01 (and, probably, 5.02) all free memory on re-describe, but 5.00 didn't free and gave memory leaks unless you did it manually. This set of versions would correspond to the changes I've had to make to my code. However, once I got the change back, I started using a #define to indicate whether the described SQLDA structure should be released or not. And I haven't yet ensured that I have all the backwards compatability information in place. There is, I suppose, one other possibility, namely that I was somehow using a buggy debugging malloc package. However, since I haven't had to change that for several years, I think it unlikely. I do remember that I managed to get my program to run clean under one version, and then had to undo the changes in another version, because of freeing already freed memory. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>