hi holger,
i would like to test it. but before i can do that, i need to know what ressource are actually counted.
for example: a transaction holds one ressource, paging holds one ressource, as well as a channel that is associated to that subscriber's transaction. what about sms? shold an object of "struct gsm_sms" be counted as one ressource, or each sender/receiver within this structure, or all together (one for the sms, one for the sender and one for the receiver)?
i need a list of all subscriber ressources for gsm_04_11.c
regards,
andreas
On Tuesday 27 October 2009 15:26:08 Andreas.Eversberg wrote:
hi holger,
i would like to test it. but before i can do that, i need to know what ressource are actually counted.
The first step is to only count gsm_subscriber instances. E.g. start with a fresh BSC.
- Do Location Updating Request procedure and see if "show subscriber cache" on the telnet console is empty. - Use "sms send EXTENSION TEXT" and see if subscriber cache is empty afterwards - Call one phone from another, hang up, see the subscriber cache. Currently the called party (Mobile Terminated) will leak the gsm_subscriber due the mncc_send implementation and the paging down there.
for example: a transaction holds one ressource, paging holds one ressource, as well as a channel that is associated to that subscriber's transaction. what about sms? shold an object of "struct gsm_sms" be counted as one ressource, or each sender/receiver within this structure, or all together (one for the sms, one for the sender and one for the receiver)?
Currently it is just about getting subscr_get and subscr_put balanced, finding out more "live leaks" later is the next thing.
Currently the branch is doing: - Stops borrowing the gsm_subscriber to the lchan - Fixes leaks in the vty_interface_layer3.c code for subscriber action - Fixes a subscriber leak (actually two) in mncc_send.
if wanted I can attach the patches to this mail to ease reviewing.
z.