[SR-Users] Re: [sr-dev] Re: pkg memory leak when acc module cdr_enabled

Hello, quick remark regarding the multi-thread lock/mutex situation in glibc, in recent version this can be now tuned as well with the MALLOC_ARENA_MAX environment variable. This way glibc will also maintain multiple memory pool, but apparently at the cost of a higher memory consumption during run-time. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com -----Original Message----- From: Daniel-Constantin Mierla <miconda(a)gmail.com> Sent: Thursday, January 5, 2023 9:06 PM To: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>rg>; Alex Balashov <abalashov(a)evaristesys.com>om>; Henning Westerholt <hw(a)gilawa.com> Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> Subject: Re: [sr-dev] Re: [SR-Users] pkg memory leak when acc module cdr_enabled Not the original developer of the memory managers, but, iirc, one of the reasons for private memory manager was to avoid a multi-threading related lock/mutex that is done by system malloc()/free(), which is not necessary for pure multi-process application. I did not analyzed myself, but I guess this is still there if it was a valid assertion in the past. On the other hand, I am not sure of its relevant impact, a lot of modules link with external libs that use anyhow the system allocator. Another thing was (faster?) indexing of free fragments up to 16kb that would enable quick selection of a such fragment that would usually fit in a (classic) SIP request/reply or attributes related to them. But I think this is no much relevant these days, because of the auto-join (merge) of free fragments -- without the latter, there were fragmentation problems. Split of large fragments is quite fast. Then, the ability to add own troubleshooting mechanism, with special structures at the beginning and the end of allocated chunks to track the place from where the chunk was allocated/freed and detect buffer overflows by checking the overwriting of special guard values. This is something that I kind of find still pretty useful for troubleshooting and usage statistics. But this can be implemented as a new memory manager for pkg-only that uses behind directly system malloc()/free(), it is actually in my to-do list for long time, but it didn't materialized yet due to lack of spare time (or from another perspective: lack of funding :-) ). At this moment, if you install from sources, just do: make MEMPKG=sys include_modules="..." ... cfg make all make install and you get kamailio compiled to use system malloc()/free() instead of the custom pkg qm/fm/... manager. I do it when I perform static code analysis, because it enables pkg memory leak detections by those tools. So it should be fully functional, on the other hand, I don't think I run such instance in production at this moment -- there are no pkg usage stats available. For shm, the custom manager has to be kept, it is still complex to work directly with shared memory, even now most of deployments are on linux, no longer common to have sunos, solaris, vax vms, aix, ... like in early 2000s. Cheers, Daniel On 05.01.23 16:57, Alex Balashov wrote: -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com