Project

General

Profile

Actions

Bug #5854

closed

Memory leak: many 1000s of proxy_subscr_listentry

Added by keith over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
01/13/2023
Due date:
% Done:

100%

Spec Reference:

Description

After running osmo-hlr with a dGSM setup for a few hours, memory consumption points to an obvious leak, and there are thousands of

        struct proxy_subscr_listentry  contains    944 bytes in   1 blocks (ref 0) 0x55f7cf8ba070
        struct proxy_subscr_listentry  contains    944 bytes in   1 blocks (ref 0) 0x55f7cf8e4960
        struct proxy_subscr_listentry  contains    944 bytes in   1 blocks (ref 0) 0x55f7cf8e5120

I AM running a few patches on master, but nothing that allocates a proxy_subscr_listentry

Actions #1

Updated by keith over 1 year ago

  • Subject changed from Memory leak many 1000s of proxy_subscr_listentry to Memory leak: many 1000s of proxy_subscr_listentry
Actions #2

Updated by keith over 1 year ago

It's not my forte at all, but, if as in proxy_subscr_create_or_update() we have a:

e = talloc_zero(proxy, struct proxy_subscr_listentry);
llist_add(&e->entry, &proxy->subscr_list);

then should there be a corresponding talloc_free() some place?

because it's not in the gc which calls:

int _proxy_subscr_del(struct proxy_subscr_listentry *e)
{
    llist_del(&e->entry);
    return 0;
}

as far as I can make out, an llist_del() is just setting some values in memory, there no free'ing of any kind.
But I don't really know talloc.

Actions #3

Updated by laforge over 1 year ago

I'm not familiar with this specific code, but indeed it looks like you are correct, the subscr_del should also
free the proxy_subscr_listentry, unless we still expect it to have some references at this point and expect
something else to clean up later. It would be best to get @neeels or osmith input on this.

In general, you can simply try to add a talloc_free(e) after the llist_del() and see what happens. If you
don't see any segfaults later on, it is a good indication.

Actions #4

Updated by keith over 1 year ago

Added the talloc_free, and so far, no segfaults.

However, In my branch, I implemented minimal proxy inspection from the vty, and I seem to be having those entries disappear before would be expected.

I continue to investigate. Just tagging neels again.

Actions #5

Updated by neels over 1 year ago

you are completely right, it is a memleak. fix is exactly as you were:

https://gerrit.osmocom.org/c/osmo-hlr/+/30981

Actions #6

Updated by osmith over 1 year ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Thanks! Patch has been merged.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)