[OpenSIPS-Devel] [ opensips-Bugs-3411398 ] load_balancer leaks when doing lb_reload

[SourceForge.net]

Bugs item #3411398, was opened at 2011-09-19 12:26
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411398&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: load_balancer leaks when doing lb_reload

Initial Comment:
Hi,

a couple of load_balancer leaks occur when doing lb_reload. Do a while loop around a fifo lb_reload and watch it consume all available mem.

This patch fixes it.

Regards,
Walter Doekes
OSSO B.V.

P.S. Bugs are also in 1.6.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 13:46

Message:
Fix applied on trunk, 1.7 & 1.6

----------------------------------------------------------------------

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-30 13:40

Message:
Excellent. That's the one.

Ship it!



----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2011-09-30 13:27

Message:
Hi Walter,

Thanks for you patch - I did a rework of it (see the new attached patched)
taking into consideration your warning regarding dst - please double check
it.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Walter Doekes (wdoekes)
Date: 2011-09-29 14:10

Message:
BEWARE:

I notice that my shm_free(dst); in load_balanced/lb_data.c (add_lb_dsturi)
is not quite right.

Error handling is not what it's supposed to be there, and simply freeing
dst is not good enough (as it's still linked in data).

However, simply removing the added shm_free() isn't good either, as
rmap_no can now be higher than actual contents.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3411398&group_id=232389