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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers