[sr-dev] Re: [kamailio/kamailio] Suspected mem leak in the pua and request for ideas (Issue #3928)

I think the pua is cleaning the memory in normal scenario, there has been some other passing issue such as innodb locks that caused some transactions to get stuck. Sorry for confusion. I understood the point about the tm callbacks. I am still investigating some mem leak in usrloc for XAVP when we "ucontact.c", new_ucontact, shm_str_dup and xavp_new_value were quite hungry as seen in the gdb. There is something else in the usrloc module where we have seen when using DB-only mode with xavp_contact parameter, the memory allocated for the xavp and temporary contact may be not released. @miconda ``` b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1084) ruid.len = 0; b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1085) if(c->ruid.len > 0 && ul_xavp_contact_name.s != NULL) { b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1086) /* clone ruid to delete attributes out of lock */ b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1087) if(c->ruid.len < RUIDBUF_SIZE - 2) { b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1088) memcpy(ruidbuf, c->ruid.s, c->ruid.len); b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1089) ruidbuf[c->ruid.len] = '\0'; b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1090) ruid.s = ruidbuf; b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1091) ruid.len = c->ruid.len; b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1092) } else { 12dbf48d421 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-30 16:58:45 +0200 1093) LM_ERR("ruid is too long %d for %.*s\n", c->ruid.len, f3d00c91a79 src/modules/usrloc/udomain.c (Victor Seva 2023-02-09 11:45:29 +0100 1094) aor.len, aor.s); b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1095) } b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1096) } 00000000000 src/modules/usrloc/udomain.c (Not Committed Yet 2024-07-25 13:42:15 +0200 1097) mem_delete_ucontact(&r, c); f3cf0a2f4e6 src/modules/usrloc/udomain.c (Victor Seva 2019-10-03 14:21:35 +0200 1098) release_urecord(&r); f3d00c91a79 src/modules/usrloc/udomain.c (Victor Seva 2023-02-09 11:45:29 +0100 1099) unlock_udomain(_d, &aor); b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1100) if(ruid.len > 0 && ul_xavp_contact_name.s != NULL) { b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1101) /* delete attributes by ruid */ b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1102) uldb_delete_attrs_ruid(_d->name, &ruid); b642263a083 src/modules/usrloc/udomain.c (Daniel-Constantin Mierla 2019-07-29 10:54:41 +0200 1103) ``` maybe we need this line to engage mem_delete_ucontact(). The delete_ucontact also in DB-only mode calls mem_delete_ucontact -> free_ucontact but in timer function for DB-only this is not getting done. I will try to do this locally and stress test it. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3928#issuecomment-2250132949 You are receiving this because you commented. Message ID: &lt;kamailio/kamailio/issues/3928/2250132949(a)github.com&gt;