Hello to all,
I'm using the latest CVS 1_0_0 and I got the following message in the log after a "record_route_preset( "213.191.xxx.xxx:5060;nat=yes" )":
record_route_preset(): No memory left
Why this comes?
Regards Bastian
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5138 from 28.01.2006 Virus news: www.antiviruslab.com
Hi Bastian,
looks like you openser runs out of private memory (pkg memory) - this may happen either because of insufficient mem, either due a mem leak.
Does is happens after running for a long time? or quite soon after start?
first try to increase the pkg memory - see config.h file, the PKG_MEM_POOL_SIZE define. By default, the size is of 1 M. If the problem persists, please report back.
regards, bogdan
Bastian Schern wrote:
Hello to all,
I'm using the latest CVS 1_0_0 and I got the following message in the log after a "record_route_preset( "213.191.xxx.xxx:5060;nat=yes" )":
record_route_preset(): No memory left
Why this comes?
Regards Bastian
Virus checked by G DATA AntiVirusKit Version: AVK 16.5138 from 28.01.2006 Virus news: www.antiviruslab.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
looks like you openser runs out of private memory (pkg memory) - this may happen either because of insufficient mem, either due a mem leak.
Does is happens after running for a long time? or quite soon after start?
It will occur quite soon after starting OpenSER.
first try to increase the pkg memory - see config.h file, the PKG_MEM_POOL_SIZE define. By default, the size is of 1 M. If the problem persists, please report back.
I changed PKG_MEM_POOL_SIZE to 2*1024*1024 but it is still the same. Is it still to low?
Regards Bastian
regards, bogdan
Bastian Schern wrote:
Hello to all,
I'm using the latest CVS 1_0_0 and I got the following message in the log after a "record_route_preset( "213.191.xxx.xxx:5060;nat=yes" )":
record_route_preset(): No memory left
Why this comes?
Regards Bastian
Virus checked by G DATA AntiVirusKit Version: AVK 16.5138 from 28.01.2006 Virus news: www.antiviruslab.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5183 from 30.01.2006 Virus news: www.antiviruslab.com
Hi,
look like something is not right - please compile the memory debug support (in Makefile.defs set DBG_QM_MALLOC define and remove F_MALLOC - Note: you need to recompile everything).
run in no fork mode with debug=9 and wait for the error to appear. first, see how much memory the malloc tries to grab. second, hit the process with SIGUSR1 to force memory dump - see if there is something strange there.
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
looks like you openser runs out of private memory (pkg memory) - this may happen either because of insufficient mem, either due a mem leak.
Does is happens after running for a long time? or quite soon after start?
It will occur quite soon after starting OpenSER.
first try to increase the pkg memory - see config.h file, the PKG_MEM_POOL_SIZE define. By default, the size is of 1 M. If the problem persists, please report back.
I changed PKG_MEM_POOL_SIZE to 2*1024*1024 but it is still the same. Is it still to low?
Regards Bastian
regards, bogdan
Bastian Schern wrote:
Hello to all,
I'm using the latest CVS 1_0_0 and I got the following message in the log after a "record_route_preset( "213.191.xxx.xxx:5060;nat=yes" )":
record_route_preset(): No memory left
Why this comes?
Regards Bastian
Virus checked by G DATA AntiVirusKit Version: AVK 16.5138 from 28.01.2006 Virus news: www.antiviruslab.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Virus checked by G DATA AntiVirusKit Version: AVK 16.5183 from 30.01.2006 Virus news: www.antiviruslab.com
Hi Bogdan,
I compiled OpenSER with memory debugging and all other settings you recommend to me. After that I got the following debug output:
--- snip --- [...] 0(31223) xl_printf: final buffer length 125 0(31223) Wed Feb 1 00:31:43 2006: sip:00045977408@sipbase.de;tag=77lh74wsus : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(31223) qm_malloc(0x8114d40, 32) called from data_lump.c: anchor_lump(351) 0(31223) qm_malloc(0x8114d40, 32) returns address 0x815a390 frag. 0x815a378 (size=32) on 1 -th hit 0(31223) qm_malloc(0x8114d40, 1074638763) called from record.c: record_route_preset(373) 0(31223) record_route_preset(): No memory left 0(31223) parse_headers: flags=200 [...] --- snip ---
It looks like qm_malloc tries to allocate 1074638763 Bytes (1024 MB). I think this is really strange!
In the memory dump I don't see something strange.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi,
look like something is not right - please compile the memory debug support (in Makefile.defs set DBG_QM_MALLOC define and remove F_MALLOC - Note: you need to recompile everything).
run in no fork mode with debug=9 and wait for the error to appear. first, see how much memory the malloc tries to grab. second, hit the process with SIGUSR1 to force memory dump - see if there is something strange there.
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
looks like you openser runs out of private memory (pkg memory) - this may happen either because of insufficient mem, either due a mem leak.
Does is happens after running for a long time? or quite soon after start?
It will occur quite soon after starting OpenSER.
first try to increase the pkg memory - see config.h file, the PKG_MEM_POOL_SIZE define. By default, the size is of 1 M. If the problem persists, please report back.
I changed PKG_MEM_POOL_SIZE to 2*1024*1024 but it is still the same. Is it still to low?
Regards Bastian
regards, bogdan
Bastian Schern wrote:
Hello to all,
I'm using the latest CVS 1_0_0 and I got the following message in the log after a "record_route_preset( "213.191.xxx.xxx:5060;nat=yes" )":
record_route_preset(): No memory left
Why this comes?
Regards Bastian
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5200 from 31.01.2006 Virus news: www.antiviruslab.com
Hi Bastian,
I made a fast overview/testing and I found no problem with record_route_preset() function. Are you calling it directly from script or from another module....the bogus length may by due an invalid param.
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
I compiled OpenSER with memory debugging and all other settings you recommend to me. After that I got the following debug output:
--- snip --- [...] 0(31223) xl_printf: final buffer length 125 0(31223) Wed Feb 1 00:31:43 2006: sip:00045977408@sipbase.de;tag=77lh74wsus : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(31223) qm_malloc(0x8114d40, 32) called from data_lump.c: anchor_lump(351) 0(31223) qm_malloc(0x8114d40, 32) returns address 0x815a390 frag. 0x815a378 (size=32) on 1 -th hit 0(31223) qm_malloc(0x8114d40, 1074638763) called from record.c: record_route_preset(373) 0(31223) record_route_preset(): No memory left 0(31223) parse_headers: flags=200 [...] --- snip ---
It looks like qm_malloc tries to allocate 1074638763 Bytes (1024 MB). I think this is really strange!
In the memory dump I don't see something strange.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi,
look like something is not right - please compile the memory debug support (in Makefile.defs set DBG_QM_MALLOC define and remove F_MALLOC - Note: you need to recompile everything).
run in no fork mode with debug=9 and wait for the error to appear. first, see how much memory the malloc tries to grab. second, hit the process with SIGUSR1 to force memory dump - see if there is something strange there.
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
looks like you openser runs out of private memory (pkg memory) - this may happen either because of insufficient mem, either due a mem leak.
Does is happens after running for a long time? or quite soon after start?
It will occur quite soon after starting OpenSER.
first try to increase the pkg memory - see config.h file, the PKG_MEM_POOL_SIZE define. By default, the size is of 1 M. If the problem persists, please report back.
I changed PKG_MEM_POOL_SIZE to 2*1024*1024 but it is still the same. Is it still to low?
Regards Bastian
regards, bogdan
Bastian Schern wrote:
Hello to all,
I'm using the latest CVS 1_0_0 and I got the following message in the log after a "record_route_preset( "213.191.xxx.xxx:5060;nat=yes" )":
record_route_preset(): No memory left
Why this comes?
Regards Bastian
Virus checked by G DATA AntiVirusKit Version: AVK 16.5200 from 31.01.2006 Virus news: www.antiviruslab.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi,
I call record_route_present() directly from the script:
--- snip --- #---------------------------------------------------------------- # record route section #---------------------------------------------------------------- if( method == "INVITE" && client_nat_test( "3" ) ) { xlog( "L_INFO", "$Tf: <$fu>;tag=$ft : record_route_preset( "217.160.188.74:5060;nat=yes" )\n" ); record_route_preset( "217.160.188.74:5060;nat=yes" ); } else if( method != "REGISTER" ) { xlog( "L_INFO", "$Tf: <$fu>;tag=$ft : record_route()\n" ); record_route(); } --- snap ---
I don't see what's going wrong.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I made a fast overview/testing and I found no problem with record_route_preset() function. Are you calling it directly from script or from another module....the bogus length may by due an invalid param.
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
I compiled OpenSER with memory debugging and all other settings you recommend to me. After that I got the following debug output:
--- snip --- [...] 0(31223) xl_printf: final buffer length 125 0(31223) Wed Feb 1 00:31:43 2006: sip:00045977408@sipbase.de;tag=77lh74wsus : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(31223) qm_malloc(0x8114d40, 32) called from data_lump.c: anchor_lump(351) 0(31223) qm_malloc(0x8114d40, 32) returns address 0x815a390 frag. 0x815a378 (size=32) on 1 -th hit 0(31223) qm_malloc(0x8114d40, 1074638763) called from record.c: record_route_preset(373) 0(31223) record_route_preset(): No memory left 0(31223) parse_headers: flags=200 [...] --- snip ---
It looks like qm_malloc tries to allocate 1074638763 Bytes (1024 MB). I think this is really strange!
In the memory dump I don't see something strange.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi,
look like something is not right - please compile the memory debug support (in Makefile.defs set DBG_QM_MALLOC define and remove F_MALLOC - Note: you need to recompile everything).
run in no fork mode with debug=9 and wait for the error to appear. first, see how much memory the malloc tries to grab. second, hit the process with SIGUSR1 to force memory dump - see if there is something strange there.
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
looks like you openser runs out of private memory (pkg memory) - this may happen either because of insufficient mem, either due a mem leak.
Does is happens after running for a long time? or quite soon after start?
It will occur quite soon after starting OpenSER.
first try to increase the pkg memory - see config.h file, the PKG_MEM_POOL_SIZE define. By default, the size is of 1 M. If the problem persists, please report back.
I changed PKG_MEM_POOL_SIZE to 2*1024*1024 but it is still the same. Is it still to low?
Regards Bastian
regards, bogdan
Bastian Schern wrote:
Hello to all,
I'm using the latest CVS 1_0_0 and I got the following message in the log after a "record_route_preset( "213.191.xxx.xxx:5060;nat=yes" )":
record_route_preset(): No memory left
Why this comes?
Regards Bastian
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5183 from 30.01.2006 Virus news: www.antiviruslab.com
Hi,
apply the attached patch and look for debug messages starting with "***:" they should give us a clue about the len value... Please send me the output (only that msgs).
regards, bogdan
Bastian Schern wrote:
Hi,
I call record_route_present() directly from the script:
--- snip --- #---------------------------------------------------------------- # record route section #---------------------------------------------------------------- if( method == "INVITE" && client_nat_test( "3" ) ) { xlog( "L_INFO", "$Tf: <$fu>;tag=$ft : record_route_preset( "217.160.188.74:5060;nat=yes" )\n" ); record_route_preset( "217.160.188.74:5060;nat=yes" ); } else if( method != "REGISTER" ) { xlog( "L_INFO", "$Tf: <$fu>;tag=$ft : record_route()\n" ); record_route(); } --- snap ---
I don't see what's going wrong.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I made a fast overview/testing and I found no problem with record_route_preset() function. Are you calling it directly from script or from another module....the bogus length may by due an invalid param.
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
I compiled OpenSER with memory debugging and all other settings you recommend to me. After that I got the following debug output:
--- snip --- [...] 0(31223) xl_printf: final buffer length 125 0(31223) Wed Feb 1 00:31:43 2006: sip:00045977408@sipbase.de;tag=77lh74wsus : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(31223) qm_malloc(0x8114d40, 32) called from data_lump.c: anchor_lump(351) 0(31223) qm_malloc(0x8114d40, 32) returns address 0x815a390 frag. 0x815a378 (size=32) on 1 -th hit 0(31223) qm_malloc(0x8114d40, 1074638763) called from record.c: record_route_preset(373) 0(31223) record_route_preset(): No memory left 0(31223) parse_headers: flags=200 [...] --- snip ---
It looks like qm_malloc tries to allocate 1074638763 Bytes (1024 MB). I think this is really strange!
In the memory dump I don't see something strange.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi,
look like something is not right - please compile the memory debug support (in Makefile.defs set DBG_QM_MALLOC define and remove F_MALLOC - Note: you need to recompile everything).
run in no fork mode with debug=9 and wait for the error to appear. first, see how much memory the malloc tries to grab. second, hit the process with SIGUSR1 to force memory dump - see if there is something strange there.
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
looks like you openser runs out of private memory (pkg memory) - this may happen either because of insufficient mem, either due a mem leak.
Does is happens after running for a long time? or quite soon after start?
It will occur quite soon after starting OpenSER.
first try to increase the pkg memory - see config.h file, the PKG_MEM_POOL_SIZE define. By default, the size is of 1 M. If the problem persists, please report back.
I changed PKG_MEM_POOL_SIZE to 2*1024*1024 but it is still the same. Is it still to low?
Regards Bastian
regards, bogdan
Bastian Schern wrote:
> Hello to all, > > I'm using the latest CVS 1_0_0 and I got the following message > in the log after a "record_route_preset( > "213.191.xxx.xxx:5060;nat=yes" )": > > record_route_preset(): No memory left > > Why this comes? > > Regards > Bastian
Virus checked by G DATA AntiVirusKit Version: AVK 16.5183 from 30.01.2006 Virus news: www.antiviruslab.com
? modules/rr/.record.c.swp Index: modules/rr/record.c =================================================================== RCS file: /cvsroot/openser/sip-server/modules/rr/record.c,v retrieving revision 1.4 diff -u -r1.4 record.c --- modules/rr/record.c 22 Nov 2005 12:35:30 -0000 1.4 +++ modules/rr/record.c 2 Feb 2006 14:01:58 -0000 @@ -329,6 +329,9 @@ char* hdr, *p; int hdr_len;
+ DBG("***: str ptr=%p, str len=%d, str s=%p",((str*)_data), + ((str*)_data)->len, ((str*)_data)->s); + from = 0; user.len = 0; user.s = 0; Index: modules/rr/rr_mod.c =================================================================== RCS file: /cvsroot/openser/sip-server/modules/rr/rr_mod.c,v retrieving revision 1.6 diff -u -r1.6 rr_mod.c --- modules/rr/rr_mod.c 24 Jan 2006 20:56:27 -0000 1.6 +++ modules/rr/rr_mod.c 2 Feb 2006 14:01:58 -0000 @@ -170,6 +170,7 @@ s->s = (char*)*param; s->len = strlen(s->s); + DBG("***: str ptr=%p, str len=%d, str s=%p",s,s->len,s->s); *param = (void*)s; }
Hi Bogdan,
I applied your patch and got that results: --- snip --- [...]
0(0) xl_parse_format: format parsed OK: [4] items 0(0) fixing /lib/openser/modules/ record_route_preset 0(0) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(0) fixing /lib/openser/modules/ xlog 0(0) xl_parse_format: parsing [$Tf: <$fu>;tag=$ft : record_route()
[...]
0(14144) xl_printf: final buffer length 125 0(14144) Fri Feb 3 00:23:20 2006: sip:00045977408@sipbase.de;tag=etlg7wbdxp : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(14144) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(14144) record_route_preset(): No memory left 0(14144) parse_headers: flags=200
[...]
0(14144) xl_printf: final buffer length 125 0(14144) Fri Feb 3 00:23:20 2006: sip:00045977408@sipbase.de;tag=etlg7wbdxp : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(14144) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(14144) record_route_preset(): No memory left 0(14144) parse_headers: flags=200 0(14144) DEBUG: get_hdr_body : content_length=297 0(14144) found end of header 0(14144) find_first_route: No Route headers found
[...] --- snap ---
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi,
apply the attached patch and look for debug messages starting with "***:" they should give us a clue about the len value... Please send me the output (only that msgs).
regards, bogdan
Bastian Schern wrote:
Hi,
I call record_route_present() directly from the script:
--- snip --- #---------------------------------------------------------------- # record route section #---------------------------------------------------------------- if( method == "INVITE" && client_nat_test( "3" ) ) { xlog( "L_INFO", "$Tf: <$fu>;tag=$ft : record_route_preset( "217.160.188.74:5060;nat=yes" )\n" ); record_route_preset( "217.160.188.74:5060;nat=yes" ); } else if( method != "REGISTER" ) { xlog( "L_INFO", "$Tf: <$fu>;tag=$ft : record_route()\n" ); record_route(); } --- snap ---
I don't see what's going wrong.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I made a fast overview/testing and I found no problem with record_route_preset() function. Are you calling it directly from script or from another module....the bogus length may by due an invalid param.
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
I compiled OpenSER with memory debugging and all other settings you recommend to me. After that I got the following debug output:
--- snip --- [...] 0(31223) xl_printf: final buffer length 125 0(31223) Wed Feb 1 00:31:43 2006: sip:00045977408@sipbase.de;tag=77lh74wsus : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(31223) qm_malloc(0x8114d40, 32) called from data_lump.c: anchor_lump(351) 0(31223) qm_malloc(0x8114d40, 32) returns address 0x815a390 frag. 0x815a378 (size=32) on 1 -th hit 0(31223) qm_malloc(0x8114d40, 1074638763) called from record.c: record_route_preset(373) 0(31223) record_route_preset(): No memory left 0(31223) parse_headers: flags=200 [...] --- snip ---
It looks like qm_malloc tries to allocate 1074638763 Bytes (1024 MB). I think this is really strange!
In the memory dump I don't see something strange.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi,
look like something is not right - please compile the memory debug support (in Makefile.defs set DBG_QM_MALLOC define and remove F_MALLOC - Note: you need to recompile everything).
run in no fork mode with debug=9 and wait for the error to appear. first, see how much memory the malloc tries to grab. second, hit the process with SIGUSR1 to force memory dump - see if there is something strange there.
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
> Hi Bastian, > > looks like you openser runs out of private memory (pkg memory) - > this may happen either because of insufficient mem, either due a > mem leak. > > Does is happens after running for a long time? or quite soon > after start? >
It will occur quite soon after starting OpenSER.
> first try to increase the pkg memory - see config.h file, the > PKG_MEM_POOL_SIZE define. By default, the size is of 1 M. If the > problem persists, please report back. >
I changed PKG_MEM_POOL_SIZE to 2*1024*1024 but it is still the same. Is it still to low?
Regards Bastian
> regards, > bogdan > > Bastian Schern wrote: > >> Hello to all, >> >> I'm using the latest CVS 1_0_0 and I got the following message >> in the log after a "record_route_preset( >> "213.191.xxx.xxx:5060;nat=yes" )": >> >> record_route_preset(): No memory left >> >> Why this comes? >> >> Regards >> Bastian > >
Virus checked by G DATA AntiVirusKit Version: AVK 16.5183 from 30.01.2006 Virus news: www.antiviruslab.com
? modules/rr/.record.c.swp Index: modules/rr/record.c =================================================================== RCS file: /cvsroot/openser/sip-server/modules/rr/record.c,v retrieving revision 1.4 diff -u -r1.4 record.c --- modules/rr/record.c 22 Nov 2005 12:35:30 -0000 1.4 +++ modules/rr/record.c 2 Feb 2006 14:01:58 -0000 @@ -329,6 +329,9 @@ char* hdr, *p; int hdr_len;
- DBG("***: str ptr=%p, str len=%d, str s=%p",((str*)_data),
((str*)_data)->len, ((str*)_data)->s);- from = 0; user.len = 0; user.s = 0;
Index: modules/rr/rr_mod.c
RCS file: /cvsroot/openser/sip-server/modules/rr/rr_mod.c,v retrieving revision 1.6 diff -u -r1.6 rr_mod.c --- modules/rr/rr_mod.c 24 Jan 2006 20:56:27 -0000 1.6 +++ modules/rr/rr_mod.c 2 Feb 2006 14:01:58 -0000 @@ -170,6 +170,7 @@ s->s = (char*)*param; s->len = strlen(s->s);
DBG("***: str ptr=%p, str len=%d, str s=%p",s,s->len,s->s);
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5261 from 02.02.2006 Virus news: www.antiviruslab.com
Hi Bastian,
look like the problem is not generated by the script parameter, but because of some values extract from the SIP msg (like user and from tag). please revert the previous patch and apply this new one - it will report the len of the constructed hdr after each step - it will hep to identify the bogus value.
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
I applied your patch and got that results: --- snip --- [...]
0(0) xl_parse_format: format parsed OK: [4] items 0(0) fixing /lib/openser/modules/ record_route_preset 0(0) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(0) fixing /lib/openser/modules/ xlog 0(0) xl_parse_format: parsing [$Tf: <$fu>;tag=$ft : record_route()
[...]
0(14144) xl_printf: final buffer length 125 0(14144) Fri Feb 3 00:23:20 2006: sip:00045977408@sipbase.de;tag=etlg7wbdxp : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(14144) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(14144) record_route_preset(): No memory left 0(14144) parse_headers: flags=200
[...]
0(14144) xl_printf: final buffer length 125 0(14144) Fri Feb 3 00:23:20 2006: sip:00045977408@sipbase.de;tag=etlg7wbdxp : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(14144) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(14144) record_route_preset(): No memory left 0(14144) parse_headers: flags=200 0(14144) DEBUG: get_hdr_body : content_length=297 0(14144) found end of header 0(14144) find_first_route: No Route headers found
[...] --- snap ---
Regards Bastian
? modules/rr/.record.c.swp Index: modules/rr/record.c =================================================================== RCS file: /cvsroot/openser/sip-server/modules/rr/record.c,v retrieving revision 1.4 diff -u -r1.4 record.c --- modules/rr/record.c 22 Nov 2005 12:35:30 -0000 1.4 +++ modules/rr/record.c 3 Feb 2006 11:24:19 -0000 @@ -357,12 +357,16 @@ }
hdr_len = RR_PREFIX_LEN; - if (user.len) + if (user.len) { hdr_len += user.len + 1; /* @ */ + DBG("***: after adding user, len=%d\n",hdr_len); + } hdr_len += ((str*)_data)->len; + DBG("***: after adding IP, len=%d\n",hdr_len);
if (append_fromtag && from->tag_value.len) { hdr_len += RR_FROMTAG_LEN + from->tag_value.len; + DBG("***: after adding fom tag, len=%d\n",hdr_len); } if (enable_full_lr) {
Hi Bogdan,
i applied the new patch to record.c and got these results:
--- snip ---
0(29780) xl_printf: final buffer length 125 0(29780) Sat Feb 4 00:04:31 2006: sip:00045977408@sipbase.de;tag=q1snnhms5k : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(29780) ***: after adding user, len=1074334712 0(29780) ***: after adding IP, len=1074334739 0(29780) ***: after adding fom tag, len=1074334755 0(29780) record_route_preset(): No memory left 0(29780) parse_headers: flags=200 0(29780) DEBUG: get_hdr_body : content_length=295 0(29780) found end of header
[...]
0(29780) parse_headers: flags=80 0(29780) xl_printf: final buffer length 125 0(29780) Sat Feb 4 00:04:31 2006: sip:00045977408@sipbase.de;tag=q1snnhms5k : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(29780) ***: after adding user, len=1074334712 0(29780) ***: after adding IP, len=1074334739 0(29780) ***: after adding fom tag, len=1074334755 0(29780) record_route_preset(): No memory left 0(29780) parse_headers: flags=200 0(29780) DEBUG: get_hdr_body : content_length=295 0(29780) found end of header
--- snap ---
It looks like there is a problem with the user. Could it be that the tailing "000" are the problem?
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
look like the problem is not generated by the script parameter, but because of some values extract from the SIP msg (like user and from tag). please revert the previous patch and apply this new one - it will report the len of the constructed hdr after each step - it will hep to identify the bogus value.
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
I applied your patch and got that results: --- snip --- [...]
0(0) xl_parse_format: format parsed OK: [4] items 0(0) fixing /lib/openser/modules/ record_route_preset 0(0) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(0) fixing /lib/openser/modules/ xlog 0(0) xl_parse_format: parsing [$Tf: <$fu>;tag=$ft : record_route()
[...]
0(14144) xl_printf: final buffer length 125 0(14144) Fri Feb 3 00:23:20 2006: sip:00045977408@sipbase.de;tag=etlg7wbdxp : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(14144) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(14144) record_route_preset(): No memory left 0(14144) parse_headers: flags=200
[...]
0(14144) xl_printf: final buffer length 125 0(14144) Fri Feb 3 00:23:20 2006: sip:00045977408@sipbase.de;tag=etlg7wbdxp : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(14144) ***: str ptr=0x8129e50, str len=27, str s=0x8119a30 0(14144) record_route_preset(): No memory left 0(14144) parse_headers: flags=200 0(14144) DEBUG: get_hdr_body : content_length=297 0(14144) found end of header 0(14144) find_first_route: No Route headers found
[...] --- snap ---
Regards Bastian
? modules/rr/.record.c.swp Index: modules/rr/record.c =================================================================== RCS file: /cvsroot/openser/sip-server/modules/rr/record.c,v retrieving revision 1.4 diff -u -r1.4 record.c --- modules/rr/record.c 22 Nov 2005 12:35:30 -0000 1.4 +++ modules/rr/record.c 3 Feb 2006 11:24:19 -0000 @@ -357,12 +357,16 @@ }
hdr_len = RR_PREFIX_LEN;
- if (user.len)
if (user.len) { hdr_len += user.len + 1; /* @ */
DBG("***: after adding user, len=%d\n",hdr_len);} hdr_len += ((str*)_data)->len;
DBG("***: after adding IP, len=%d\n",hdr_len);
if (append_fromtag && from->tag_value.len) { hdr_len += RR_FROMTAG_LEN + from->tag_value.len;
DBG("***: after adding fom tag, len=%d\n",hdr_len);}
if (enable_full_lr) {
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5268 from 03.02.2006 Virus news: www.antiviruslab.com
Hi Bastian,
at least we found the guilty element. As the user is extracted from the msg, can please post the message that triggers this error (or at least the uri..). hexa version is needed if non printing chars are included.
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
i applied the new patch to record.c and got these results:
--- snip ---
0(29780) xl_printf: final buffer length 125 0(29780) Sat Feb 4 00:04:31 2006: sip:00045977408@sipbase.de;tag=q1snnhms5k : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(29780) ***: after adding user, len=1074334712 0(29780) ***: after adding IP, len=1074334739 0(29780) ***: after adding fom tag, len=1074334755 0(29780) record_route_preset(): No memory left 0(29780) parse_headers: flags=200 0(29780) DEBUG: get_hdr_body : content_length=295 0(29780) found end of header
[...]
0(29780) parse_headers: flags=80 0(29780) xl_printf: final buffer length 125 0(29780) Sat Feb 4 00:04:31 2006: sip:00045977408@sipbase.de;tag=q1snnhms5k : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(29780) ***: after adding user, len=1074334712 0(29780) ***: after adding IP, len=1074334739 0(29780) ***: after adding fom tag, len=1074334755 0(29780) record_route_preset(): No memory left 0(29780) parse_headers: flags=200 0(29780) DEBUG: get_hdr_body : content_length=295 0(29780) found end of header
--- snap ---
It looks like there is a problem with the user. Could it be that the tailing "000" are the problem?
Regards Bastian
Hi Bogdan,
here is the INVITE message that triggers the error:
--- snip ---
INVITE sip:08003301000@sipbase.de;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.10.198:5060;branch=z9hG4bK-arcon5ii9sog;rport From: "Bastian Schern" sip:00045977408@sipbase.de;tag=8q633ozick To: sip:08003301000@sipbase.de;user=phone Call-ID: 3c3c074edaff-jcv2kbkdvtuv@192-168-10-198 CSeq: 2 INVITE Max-Forwards: 69 Contact: sip:00045977408@192.168.10.198:5060;line=udyy8b7h P-Key-Flags: keys="3" User-Agent: snom200-3.56z Accept-Language: en Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Allow-Events: talk, hold, refer Supported: timer, 100rel, replaces Session-Expires: 3600 Proxy-Authorization: Digest username="00045977408",realm="sipbase.net",nonce="43e49b45a79356873dad46b5f9361160742b100c",uri="sip:08003301000@sipbase.de;user=phone",qop=auth,nc=00000001,cnonce="02d0baeb",response="a531362656079c26b4bf414a5df0d736",algorithm=md5 Content-Type: application/sdp Content-Length: 297
v=0 o=root 1196819338 1196819338 IN IP4 192.168.10.198 s=call c=IN IP4 192.168.10.198 t=0 0 m=audio 10196 RTP/AVP 8 0 3 18 101 a=rtpmap:8 pcma/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
--- snap ---
I'm sure that no unprintable characters inside.
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
at least we found the guilty element. As the user is extracted from the msg, can please post the message that triggers this error (or at least the uri..). hexa version is needed if non printing chars are included.
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
i applied the new patch to record.c and got these results:
--- snip ---
0(29780) xl_printf: final buffer length 125 0(29780) Sat Feb 4 00:04:31 2006: sip:00045977408@sipbase.de;tag=q1snnhms5k : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(29780) ***: after adding user, len=1074334712 0(29780) ***: after adding IP, len=1074334739 0(29780) ***: after adding fom tag, len=1074334755 0(29780) record_route_preset(): No memory left 0(29780) parse_headers: flags=200 0(29780) DEBUG: get_hdr_body : content_length=295 0(29780) found end of header
[...]
0(29780) parse_headers: flags=80 0(29780) xl_printf: final buffer length 125 0(29780) Sat Feb 4 00:04:31 2006: sip:00045977408@sipbase.de;tag=q1snnhms5k : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(29780) ***: after adding user, len=1074334712 0(29780) ***: after adding IP, len=1074334739 0(29780) ***: after adding fom tag, len=1074334755 0(29780) record_route_preset(): No memory left 0(29780) parse_headers: flags=200 0(29780) DEBUG: get_hdr_body : content_length=295 0(29780) found end of header
--- snap ---
It looks like there is a problem with the user. Could it be that the tailing "000" are the problem?
Regards Bastian
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5292 from 04.02.2006 Virus news: www.antiviruslab.com
Hi Bastian,
I run a lot of tests against this message, but nothing...
So , first some question? is the param "add_username" enabled? are you using the latest CVS version?
Second, here is a third patch - please send me the results..
BTW - is there any way to speed up this remote debugging ? access to the machine is possible? ...
regards, bogdan
Bastian Schern wrote:
Hi Bogdan,
here is the INVITE message that triggers the error:
--- snip ---
INVITE sip:08003301000@sipbase.de;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.10.198:5060;branch=z9hG4bK-arcon5ii9sog;rport From: "Bastian Schern" sip:00045977408@sipbase.de;tag=8q633ozick To: sip:08003301000@sipbase.de;user=phone Call-ID: 3c3c074edaff-jcv2kbkdvtuv@192-168-10-198 CSeq: 2 INVITE Max-Forwards: 69 Contact: sip:00045977408@192.168.10.198:5060;line=udyy8b7h P-Key-Flags: keys="3" User-Agent: snom200-3.56z Accept-Language: en Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Allow-Events: talk, hold, refer Supported: timer, 100rel, replaces Session-Expires: 3600 Proxy-Authorization: Digest username="00045977408",realm="sipbase.net",nonce="43e49b45a79356873dad46b5f9361160742b100c",uri="sip:08003301000@sipbase.de;user=phone",qop=auth,nc=00000001,cnonce="02d0baeb",response="a531362656079c26b4bf414a5df0d736",algorithm=md5
Content-Type: application/sdp Content-Length: 297
v=0 o=root 1196819338 1196819338 IN IP4 192.168.10.198 s=call c=IN IP4 192.168.10.198 t=0 0 m=audio 10196 RTP/AVP 8 0 3 18 101 a=rtpmap:8 pcma/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv
--- snap ---
I'm sure that no unprintable characters inside.
Regards Bastian
? modules/rr/.record.c.swp Index: modules/rr/record.c =================================================================== RCS file: /cvsroot/openser/sip-server/modules/rr/record.c,v retrieving revision 1.4 diff -u -r1.4 record.c --- modules/rr/record.c 22 Nov 2005 12:35:30 -0000 1.4 +++ modules/rr/record.c 4 Feb 2006 15:24:10 -0000 @@ -86,6 +86,8 @@ struct sip_uri puri;
/* first try to look at r-uri for a username */ + DBG("**: trying uri <%.*s> len=%d\n", _m->first_line.u.request.uri.len, + _m->first_line.u.request.uri.s, _m->first_line.u.request.uri.len); if (parse_uri(_m->first_line.u.request.uri.s, _m->first_line.u.request.uri.len, &puri) < 0) { LOG(L_ERR, "get_username(): Error while parsing R-URI\n"); return -1; @@ -97,12 +99,15 @@ * was called somewhere in script's beginning) */ if (!puri.user.len && _m->new_uri.s) { + DBG("**: trying uri <%.*s> len=%d\n",_m->new_uri.len, + _m->new_uri.s, _m->new_uri.len); if (parse_uri(_m->new_uri.s, _m->new_uri.len, &puri) < 0) { LOG(L_ERR, "get_username(): Error while parsing new_uri\n"); return -2; } }
+ DBG("**: befor return uri len=%d, s=%p\n",puri.user.len, puri.user.s); _user->s = puri.user.s; _user->len = puri.user.len; return 0; @@ -339,6 +344,7 @@ "extract username\n"); return -1; } + DBG("**: return uri len=%d, s=%p\n",user.len, user.s); }
if (append_fromtag) {
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I run a lot of tests against this message, but nothing...
So , first some question? is the param "add_username" enabled? are you using the latest CVS version?
The param "add_username" was _not_ enabled. After enabling it the Error is gone away. For what the username is needed in rr?
I'm using the latest CVS rel_1_0_0.
Second, here is a third patch - please send me the results..
Results of third patch after enabling add_username: --- snip --- 0(4952) Sat Feb 4 22:47:49 2006: sip:00045977408@sipbase.de;tag=klfjsk2v77 : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(4952) **: trying uri sip:08003301000@sipbase.de;user=phone len=37 0(4952) **: befor return uri len=11, s=0x80de4ab 0(4952) **: return uri len=11, s=0x80de4ab --- snap ---
Without add_username there is no DBG output.
BTW - is there any way to speed up this remote debugging ? access to the machine is possible? ...
I think it is possible to get remote access. But I have to clarify this with before.
Regards Bastian
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5292 from 04.02.2006 Virus news: www.antiviruslab.com
Hi Bastian,
I found and fixed the problem - it was that the variable used for username remained uninitialized when "add_username" was disabled - the origins of the bug was a incomplete backport from the devel version ("add_username" param to have effect on record_route_preset also).
Thanks for the help! I have only one question - what arch and compiler are you using?
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I run a lot of tests against this message, but nothing...
So , first some question? is the param "add_username" enabled? are you using the latest CVS version?
The param "add_username" was _not_ enabled. After enabling it the Error is gone away. For what the username is needed in rr?
I'm using the latest CVS rel_1_0_0.
Second, here is a third patch - please send me the results..
Results of third patch after enabling add_username: --- snip --- 0(4952) Sat Feb 4 22:47:49 2006: sip:00045977408@sipbase.de;tag=klfjsk2v77 : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(4952) **: trying uri sip:08003301000@sipbase.de;user=phone len=37 0(4952) **: befor return uri len=11, s=0x80de4ab 0(4952) **: return uri len=11, s=0x80de4ab --- snap ---
Without add_username there is no DBG output.
BTW - is there any way to speed up this remote debugging ? access to the machine is possible? ...
I think it is possible to get remote access. But I have to clarify this with before.
Regards Bastian
Virus checked by G DATA AntiVirusKit Version: AVK 16.5292 from 04.02.2006 Virus news: www.antiviruslab.com
Hi Bogdan,
Im using gcc on SuSE Linux 9.1 with self build Kernel 2.6.14.4. The machine is a Intel Celeron with 2000 MHz.
--- snip --- # gcc --version gcc (GCC) 3.3.3 (SuSE Linux) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# uname -a Linux de5 2.6.14.4 #1 SMP Fri Dec 23 16:38:33 UTC 2005 i686 i686 i386 GNU/Linux --- snap ---
Thanks for your support. I also have a last question: I tried to checkout the bugfix but there is nothing inside the CVS.
ViewCVS says also "No Changes": http://cvs.sourceforge.net/viewcvs.py/openser/sip-server/modules/rr/record.c...
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I found and fixed the problem - it was that the variable used for username remained uninitialized when "add_username" was disabled - the origins of the bug was a incomplete backport from the devel version ("add_username" param to have effect on record_route_preset also).
Thanks for the help! I have only one question - what arch and compiler are you using?
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I run a lot of tests against this message, but nothing...
So , first some question? is the param "add_username" enabled? are you using the latest CVS version?
The param "add_username" was _not_ enabled. After enabling it the Error is gone away. For what the username is needed in rr?
I'm using the latest CVS rel_1_0_0.
Second, here is a third patch - please send me the results..
Results of third patch after enabling add_username: --- snip --- 0(4952) Sat Feb 4 22:47:49 2006: sip:00045977408@sipbase.de;tag=klfjsk2v77 : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(4952) **: trying uri sip:08003301000@sipbase.de;user=phone len=37 0(4952) **: befor return uri len=11, s=0x80de4ab 0(4952) **: return uri len=11, s=0x80de4ab --- snap ---
Without add_username there is no DBG output.
BTW - is there any way to speed up this remote debugging ? access to the machine is possible? ...
I think it is possible to get remote access. But I have to clarify this with before.
Regards Bastian
Virus checked by G DATA AntiVirusKit Version: AVK 16.5292 from 04.02.2006 Virus news: www.antiviruslab.com
____________ Virus checked by G DATA AntiVirusKit Version: AVK 16.5315 from 05.02.2006 Virus news: www.antiviruslab.com
Hi Bastian,
Thanks for the info...regarding the cvs update - the sourceforge policy is to update the public cvs (pserver) from time to time and not continuously - the fix will is already visible now.
regards, bogdan
Thanks for your support. I also have a last question: I tried to checkout the bugfix but there is nothing inside the CVS.
ViewCVS says also "No Changes": http://cvs.sourceforge.net/viewcvs.py/openser/sip-server/modules/rr/record.c...
Regards Bastian
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I found and fixed the problem - it was that the variable used for username remained uninitialized when "add_username" was disabled - the origins of the bug was a incomplete backport from the devel version ("add_username" param to have effect on record_route_preset also).
Thanks for the help! I have only one question - what arch and compiler are you using?
regards, bogdan
Bastian Schern wrote:
Bogdan-Andrei Iancu schrieb:
Hi Bastian,
I run a lot of tests against this message, but nothing...
So , first some question? is the param "add_username" enabled? are you using the latest CVS version?
The param "add_username" was _not_ enabled. After enabling it the Error is gone away. For what the username is needed in rr?
I'm using the latest CVS rel_1_0_0.
Second, here is a third patch - please send me the results..
Results of third patch after enabling add_username: --- snip --- 0(4952) Sat Feb 4 22:47:49 2006: sip:00045977408@sipbase.de;tag=klfjsk2v77 : record_route_preset( "217.160.188.74:5060;nat=yes" ) 0(4952) **: trying uri sip:08003301000@sipbase.de;user=phone len=37 0(4952) **: befor return uri len=11, s=0x80de4ab 0(4952) **: return uri len=11, s=0x80de4ab --- snap ---
Without add_username there is no DBG output.
BTW - is there any way to speed up this remote debugging ? access to the machine is possible? ...
I think it is possible to get remote access. But I have to clarify this with before.
Regards Bastian
Virus checked by G DATA AntiVirusKit Version: AVK 16.5292 from 04.02.2006 Virus news: www.antiviruslab.com
Virus checked by G DATA AntiVirusKit Version: AVK 16.5315 from 05.02.2006 Virus news: www.antiviruslab.com
-
Bastian Schern -
Bogdan-Andrei Iancu