Re: Help! Memory leak using ESQL
Posted in 1993
In article <C8s5xo.70p@world.std.com> smayo@world.std.com (Scott A Mayo) writes: > >The following little program prints no errors, but slowly consumes >all available memory: > >#include <stdio.h> >#include <string.h> >#include <stdlib.h> >#include <ctype.h> >$include sqltypes; >$include datetime; > >$char *databasename = "datab"; > >int main(void) >{ >unsigned long cnt = 0; > > $Database $databasename; > if (SQLCODE) printf("%ld\\n", SQLCODE); > > do { > $char name[64]; > > sprintf(name, "S%lu", ++cnt); /* make a unique, legal name */ > > $PREPARE $name FROM "Select user_key_a FROM mytable"; > if (SQLCODE) printf("%ld\\n", SQLCODE); > $FREE $name; > if (SQLCODE) printf("%ld\\n", SQLCODE); > } while (1); > return 0; >} > >The problem is the ++cnt in the sprintf; if you generate a new >name for each statement you prepare, memory quietly vanishes >in each iteration. Replacing ++cnt with just cnt does not lose >memory. > >Help! This is a critical problem for my app, which is a server >that (as things stand) rapidly runs out of memory and crashes >in an embarassing fashion in just a few hours of heavy use. >We use Informix/Se 4.0 on a Unisys unix machine (486 based). >I am preparing with a unique name each time because I might >be preparing lots of statements for lots of different clients, >more or less concurrently. > >If you have a workaround, please send mail to smayo@world.std.com. >I also suspect this is not the only leak; chopping the app down >to the size shown above seemed to slow the rate of leaking. >Is Online more robust about this? Is 5.0? Help! This problem has been logged as bug #15191.SE or Online makes no difference. The problem is due to free not freeing up entire memory.We keep some memory around as an optimization in case the same cusror or prepared statement is used.If one is using unique statement id or cursor name then there is no way to get the memory back. The problem will be addressed in forth coming maintenance releases. ram.