Thanks, but it is only a symtomatic treatment isn't it ?

I think I will have the same problem, but later.

Am I right ?

Mitya

Arun Kumar wrote:

increase your shared memory during compile or run ser with -m option

On 10/31/07, *Mitya* <mitya@madein.hu mailto:mitya@madein.hu> wrote:

Hi All,

I have a SER 0.9.6, and sometimes I have memory allocation problem
somehow :(


Oct 29 19:58:38 sip ser[23161]: processing REGISTER received from
x.x.x.x
Oct 29 19:58:38 sip ser[23161]: DEBUG: t_newtran: msg id=23950 ,
global
msg id=23949 , T on entrance=0xffffffff
Oct 29 19:58:38 sip ser[23161]: parse_headers: flags=-1
Oct 29 19:58:38 sip ser[23161]: DEBUG: get_hdr_body : content_length=0
Oct 29 19:58:38 sip ser[23161]: found end of header
Oct 29 19:58:38 sip ser[23161]: parse_headers: flags=60
Oct 29 19:58:38 sip ser[23161]: t_lookup_request: start searching:
hash=31874, isACK=0
Oct 29 19:58:38 sip ser[23161]: DEBUG: RFC3261 transaction
matching failed
Oct 29 19:58:38 sip ser[23161]: DEBUG: t_lookup_request: no
transaction
found
Oct 29 19:58:38 sip ser[23161]: ERROR: sip_msg_cloner: cannot
allocate
memory
Oct 29 19:58:38 sip ser[23161]: DEBUG:destroy_avp_list: destroying
list
(nil)
Oct 29 19:58:38 sip ser[23161]: ERROR: new_t: out of mem:
Oct 29 19:58:38 sip ser[23161]: ERROR: t_newtran: new_t failed


As I read in the mailing lists, it occurs, when SER has a lots of
live,
opened transactions.

It's a test SER, I think we did not have any opened transactions
(maybe
the failed ones).

Is there any mechanism in SER, what drops the too old opened (most
likely failed transactions) transactions ?

Can I get the current used shared memory somehow ?

What else can sause this problem ?

Thanks,
Mitya