Re: Big memory leak with ESQL/C library!

Posted in 2003

Plausible Indirection — 18 Sep 2003 09:12:47 -0700 — source: Usenet: comp.databases.informix

Those do look like symbols in the ESQL/C library or one of the libraries on which it is dependent; pretty easy to verify that with an nm command on UNIX or Dependency Walker on Windows. But, it is difficult to determine from the info below if the 'leak' is a bug in the ec lib or a failure of the program to free, or tell the lib to free, something that it has asked the lib to allocate. If you are sure your program is freeing statements and cursors, etc., like it is supposed to when it is done with them, then I'd look for a newer version of the CSDK or contact their technical support. 100,000 rows is really not that many, I'd be surprised to learn that others aren't processing a lot more and that they wouldn't have already complained bitterly at this kind of leak. So, I have some doubts that the fault is entirely in the ESQL/C library. Luck, CG steven@steven4u.net (steven) wrote in message news:<1e7ef8d0.0309141007.6f900be4@posting.google.com>... > My code was not linked with any other library except ESQ/C's. These > days I suspected that the program run into a big memory leak. Then I > used dmalloc(http://dmalloc.com) to debug it and got the following > report: > > ----------- cut ------------------- > ... > 1063561110: 149639: not freed: '0x80d6008|s1' (1024 bytes) from > 'ra=0x8001a221' > 1063561110: 149639: not freed: '0x80d6808|s1' (1024 bytes) from > 'ra=0x8001a221' > 1063561110: 149639: not freed: '0x80da808|s15' (1248 bytes) from > 'ra=0x8006eee7' > 1063561110: 149639: not freed: '0x80dc008|s15' (1876 bytes) from > 'ra=0x800f437c' > 1063561110: 149639: not freed: '0x80df008|s5' (1024 bytes) from > 'ra=0x8001a221' > 1063561110: 149639: not freed: '0x80df808|s5' (1024 bytes) from > 'ra=0x8001a221' > 1063561110: 149639: not freed: '0x80e0008|s5' (1920 bytes) from > 'ra=0x800f4067' > 1063561110: 149639: not freed: '0x80e1808|s5' (1044 bytes) from > 'ra=0x800f2723' > 1063561110: 149639: not freed: '0x80e4008|s1' (512 bytes) from > 'ra=0x800c751a' > 1063561110: 149639: not freed: '0x80e4408|s3' (616 bytes) from > 'ra=0x800c632c' > 1063561110: 149639: not freed: '0x80e4808|s1' (512 bytes) from > 'ra=0x800c751a' > ... > 1063561110: 149639: not freed: '0x8100fe8|s5' (16 bytes) from > 'ra=0x800cb1a9' > 1063561110: 149639: not freed: '0x8107c08|s1' (468 bytes) from > 'ra=0x800f437c' > 1063561110: 149639: total-size count source > 1063561110: 149639: 11415 344 ra=0x800c751a > 1063561110: 149639: 4232 1 ra=0x8007cbca > 1063561110: 149639: 4096 4 ra=0x8001a221 > 1063561110: 149639: 3875 28 ra=0x800f437c > 1063561110: 149639: 2618 119 ra=0x8012580a > 1063561110: 149639: 1920 1 ra=0x800f4067 > 1063561110: 149639: 1428 119 ra=0x801257fa > 1063561110: 149639: 1248 1 ra=0x8006eee7 > 1063561110: 149639: 1184 74 ra=0x800cb1a9 > 1063561110: 149639: 1044 1 ra=0x800f2723 > 1063561110: 149639: 861 92 ra=0x800f2453 > 1063561110: 149639: 720 1 ra=0x80065a7c > 1063561110: 149639: 616 1 ra=0x800c632c > 1063561110: 149639: 352 22 ra=0x800cb1ca > 1063561110: 149639: 344 1 ra=0x80069aee > 1063561110: 149639: 156 1 ra=0x800477b4 > 1063561110: 149639: 128 1 ra=0x8002949e > ... > 1063561110: 149639: 36726 825 Total of 26 > ... > ------------------- cut ----------------------------------- > > Since the DMalloc only report 'ra' (return address) instead of source > code line numbers, so I think the leaks did not come from my own code. > After I bring up a debuger (gdb) to check where those magic 'ra' > really locate, I believ I am right: > > (gdb) x 0x800c751a > 0x800c751a <gl_ext_malloc+26> > (gdb) x 0x8007cbca > 0x8007cbca <_sqrealloc+42> > (gdb) x 0x8001a221 > 0x8001a221 <_findbuf+129> > (gdb) x 0x800f437c > 0x800f437c <meAlloc+28> > (gdb) x 0x8012580a > 0x8012580a <gl_cache_registry+266> > (gdb) x 0x800f4067 > 0x800f4067 <ostcb_alloc+39> > (gdb) x 0x801257fa > 0x801257fa <gl_cache_registry+250> > ... > > I won't list all, but I think these routines above are all ESQ/C > build-in, right? > > > My program neet to read a great number of data records and > insert/update them into tables, the above is just a sample run > processing merely 300 records. In a real run with 100000 data records, > will those leaks strave my system? > > Any comments will be appreciated!