Thread: ECPG memory leak detected
Hi, I observed a memory leak in one of my applications (grew about 20MB a day) and pinned it down to be ECPG related. The path is: ecpg_alloc quote_postgres ECPGexecute ECPGdo PostgreSQL Version 7.0 (about 24th November's CVS) This leak was at least present for two months. Christof If you have a direct idea on how to fix it, drop me a mail otherwise I'll (try to) fix it myself (about next week). It's not fatal, it's simply annoying. PS: Program used for this analysis: memprof (part of gnome) (Version 0.3.0)
Attached is a patch that fixes some memory leaks in ecpg. Maybe it will help your situation. [Charset iso-8859-1 unsupported, filtering to ASCII...] > Hi, > > I observed a memory leak in one of my applications (grew about 20MB a > day) and pinned it down to be > ECPG related. > > The path is: > ecpg_alloc > quote_postgres > ECPGexecute > ECPGdo > > PostgreSQL Version 7.0 (about 24th November's CVS) > This leak was at least present for two months. > > Christof > > If you have a direct idea on how to fix it, drop me a mail otherwise > I'll (try to) fix it myself (about next week). It's not fatal, it's > simply annoying. > > PS: Program used for this analysis: memprof (part of gnome) (Version > 0.3.0) > > ************ > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 *** ecpglib.c.orig Tue Dec 14 12:27:47 1999 --- ecpglib.c Tue Dec 14 12:28:00 1999 *************** *** 528,540 **** { int slen = strlen((char *) var->value); ! if (!(newcopy = ecpg_alloc(slen + 1, stmt->lineno))) return false; ! strncpy(newcopy, (char *) var->value, slen); ! newcopy[slen] = '\0'; ! tobeinserted = newcopy; } break; case ECPGt_varchar: --- 528,540 ---- { int slen = strlen((char *) var->value); ! if (!(mallocedval = ecpg_alloc(slen + 1, stmt->lineno))) return false; ! strncpy(mallocedval, (char *) var->value, slen); ! mallocedval[slen] = '\0'; ! tobeinserted = mallocedval; } break; case ECPGt_varchar: *************** *** 1132,1144 **** con->committed = true; /* deallocate all prepared statements */ ! for (this = prep_stmts; this != NULL; this = this->next) ! { ! bool b = ECPGdeallocate(lineno, this->name); if (!b) return false; } } return true; --- 1132,1144 ---- con->committed = true; /* deallocate all prepared statements */ ! while(prep_stmts != NULL) { ! bool b = ECPGdeallocate(lineno, prep_stmts->name); if (!b) return false; } + } return true; *************** *** 1416,1421 **** --- 1416,1422 ---- else prep_stmts = this->next; + free(this); return true; } ECPGlog("deallocate_prepare: invalid statement name %s\n", name);
Bruce Momjian wrote: > > Attached is a patch that fixes some memory leaks in ecpg. Maybe it will > help your situation. > > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > Hi, > > > > I observed a memory leak in one of my applications (grew about 20MB a > > day) and pinned it down to be > > ECPG related. > > > > The path is: > > ecpg_alloc > > quote_postgres > > ECPGexecute > > ECPGdo My problem had been fixed two weeks ago. In private communication with Michael. He sent me a (short) patch. I tested it. It still works like a charm. It has been committed to CVS already. So you can safely mark this problem as solved. Christof PS: I never observed any additional leaks. So it seems I didn't hit this part of the code.
> Bruce Momjian wrote: > > > > Attached is a patch that fixes some memory leaks in ecpg. Maybe it will > > help your situation. > > > > [Charset iso-8859-1 unsupported, filtering to ASCII...] > > > Hi, > > > > > > I observed a memory leak in one of my applications (grew about 20MB a > > > day) and pinned it down to be > > > ECPG related. > > > > > > The path is: > > > ecpg_alloc > > > quote_postgres > > > ECPGexecute > > > ECPGdo > > My problem had been fixed two weeks ago. In private communication with > Michael. > He sent me a (short) patch. I tested it. It still works like a charm. It > has been committed to CVS already. > > So you can safely mark this problem as solved. > > Christof > > PS: I never observed any additional leaks. So it seems I didn't hit this > part of the code. > Man, no one tells me anything anymore. :-) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026