23 Jan
2003
23 Jan
'03
1:19 p.m.
BTW, WRT to detecting memory leaks, boehem-gc could be very useful
tool. Designed as a garbadge collector, but it is possible compile it
as a leak-detector, in which case it will wrap all malloc()/free()
operations and once per second will scan program memory for lost
references reporting if there are any.
-Maxim
Jiri Kuthan wrote:
Maxim,
Thank you very much for your report.
I'm not the code owner who has the last word, but I agree there is
a memory leak. It seems to me that insert_new_lump family is ok as
long as the calling functions care to free their lump buffers on
failure -- that's where the leak lives.
Which imho happens at few places on CVS:
+insert_new_lump_before
- save_ruri in rr/loose.c
- textops/append_hf_helper.c
- (on contrary, it is ok in maxfwd/add_maxfwd_header, rr functions
calling insert_RR, and msg_translator.c)
+insert_new_lump_after
- search_append_f in textops.c
- replace_f in textops.c
- (ok in build_req_buf...)
The memory leak is unlikely to occur, as it is triggered by lack of
private memory which (unlike shmem) hardly gets exhausted -- so
operation is fortunately not affected. It will be fixed in the next
release.
-Jiri
ps -- I swear on cscope :)
Folks,
I've noticed that there are multiple potential memory leaks in SER.
The problem is that if a insert_new_lump*() function returns a NULL
for some reason (currently the only condition is memory allocation
error), it doesn't free the memory buffer passed to it and most of
the code doesn't care to deallocate that buffer after NULL is returned.
It could be easily fixed and probably needs to before the next version
is released.
Thanks!
-Maxim
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers