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(a)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