Re: [OpenSIPS-Users] db_postgres: no private memory left
Some more information... this only occurs when issuing 'opensipsctl fifo dr_reload'. All other fifo commands seem to work without issue. Anyone have any suggestions on how I can track this down? Thanks. On Thu, Apr 21, 2011 at 8:56 AM, thrillerbee thriller...@gmail.com wrote: I'm trying to track down the source of the following errors in syslog: /usr/local/sbin/opensips[25490]: WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation /usr/local/sbin/opensips[25490]: ERROR:core:db_allocate_rows: no memory left /usr/local/sbin/opensips[25490]: ERROR:db_postgres:db_postgres_convert_rows: no private memory left What makes this even more unusual is that it will print these errors at almost exactly 30-min intervals for several hours and then just stop. For example, last night, it printed the above errors at: 23:56:00 00:26:08 00:56:08 01:26:03 01:56:05 02:26:03 02:56:01 03:26:02 and then it stopped... I see no errors in postgresql logs and I haven't yet found any issues with the actual performance of OpenSIPS. I have increased private memory to 100MB and continue to see this randomly. This OpenSIPS instance is using drouting module with about 16,000 lines in the dr_rules table. Any advice would be appreciated to help narrow down the source of these messages. Thanks, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] db_postgres: no private memory left
I'm trying to track down the source of the following errors in syslog: /usr/local/sbin/opensips[25490]: WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation /usr/local/sbin/opensips[25490]: ERROR:core:db_allocate_rows: no memory left /usr/local/sbin/opensips[25490]: ERROR:db_postgres:db_postgres_convert_rows: no private memory left What makes this even more unusual is that it will print these errors at almost exactly 30-min intervals for several hours and then just stop. For example, last night, it printed the above errors at: 23:56:00 00:26:08 00:56:08 01:26:03 01:56:05 02:26:03 02:56:01 03:26:02 and then it stopped... I see no errors in postgresql logs and I haven't yet found any issues with the actual performance of OpenSIPS. I have increased private memory to 100MB and continue to see this randomly. This OpenSIPS instance is using drouting module with about 16,000 lines in the dr_rules table. Any advice would be appreciated to help narrow down the source of these messages. Thanks, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] drouting module with append_branch() and q-values
bump.
On Tue, Mar 29, 2011 at 11:27 AM, thrillerbee thriller...@gmail.com wrote:
Hopefully my last question:
Using append_branch() and $branch allows me to add all destinations as
branches with q-values. However, I am unable to remove/edit the initial
entry in $ds as set by do_routing():
Contact: *sip:15552345678@1.1.1.1, *sip:15552345678@1.1.1.1;q=1,
sip:2215552345678@2.2.2.2;q=0.9, sip:5552345678@3.3.3.3;q=0.85,
sip:15552345678@5.5.5.5;q=0.8, sip:sip:4415552345678@4.4.4.4;q=0.75
Is there a way to prevent do_routing from adding that entry and/or remove
it after it has been added? OR is there a way to add a q-value to that
instance?
Thanks,
Ryan
On Tue, Mar 29, 2011 at 10:51 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
Nevermind on that issue; I neglected to notice that I had to create the
branch with append_branch() before setting anything.
Thanks for the help.
Ryan
On Tue, Mar 29, 2011 at 9:52 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
When I configure:
$(branch(uri)[0]) = $ru;
$(branch(q)[0]) = 100;
xlog(L_INFO,branch 0 = $(branch(uri)[0]) with q-value
$(branch(q)[0])\n);
I get this debug:
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch assigment
[0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 163
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch assigment
[0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 164
branch 0 = null with q-value null
Thanks,
Ryan
On Tue, Mar 29, 2011 at 8:19 AM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
Hi,
Another tricks:
1) you can read the pending destinations directly from AVPs, without
calling the use_next_gw() function. See:
http://www.opensips.org/html/docs/modules/1.6.x/drouting.html#id293166
2) as append_branch() does not accept variables as params, use the
$branch variable to write into:
http://www.opensips.org/Resources/DocsCoreVar16#toc15
like:
$branch = $var(x) ; #add a new SIP URI as extra branch
$(branch(q)[-1]) = 10 ; # set Q val for the last added brach
Regards,
Bogdan
Anca Vamanu wrote:
Hi thrillerbe,
I think that if you only want to build the list of selected
destinations, you can just call use_next_gw and add the uri in RURI to a
destination string ( because use_next_gw sets the RURI to the destination-
http://www.opensips.org/html/docs/modules/devel/drouting.html#id251519
).
It would be something like this:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ru\n); $var(x) = 2;
$var(ds) = $ru;
while (use_next_gw()) { $var(ds) =
$var(ds) + , + $ru;
xlog(L_INFO,After $var(x), ds is $var(ds)\n);
$var(x) = $var(x) + 1; } }
xlog(L_INFO,Destination
set is $var(ds)\n); }
Regards,
--
Anca Vamanu
OpenSIPS Developer
On 03/29/2011 01:00 AM, thrillerbee wrote:
I'm trying to get OpenSIPS to act as a REDIRECT server and have run
into a couple issues. I'm using the drouting module to do lookups.
Essentially, a dialed number could have potentially several routes, I
want
to return a 300 with these routes in the Contact header. Please tell me
if
this is foolish and/or there are better methods.
I'm running release version 1.6.4-2-notls.
With that, I've configured the following in my script:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ds\n); $var(x) = 2;
while (use_next_gw()) { append_branch();
xlog(L_INFO,After $var(x), ds is $ds\n);
$var(x) = $var(x) + 1; } } xlog(L_INFO,Destination
set
is $ds\n); }
My relevant debug output is:
After 1, ds is Contact: sip:15552345678@1.1.1.1 mailto:
sip%3A15552345678@1.1.1.1 After 2, ds is Contact: *
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2* After
3, ds is Contact: *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3* After 4, ds is Contact: *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5*,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:5552345678@3.3.3.3 mailto:sip%3A5552345678@3.3.3.3, *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5* After 5,
ds is Contact: *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3, sip:15552345678@5.5.5.5 mailto:
sip%3A15552345678@5.5.5.5, *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*
It seems that append_branch() deletes the first entry in the
destination set before adding
Re: [OpenSIPS-Users] drouting module with append_branch() and q-values
I was able to manipulate $ru as set by do_routing() to get the behavior I'm
looking for. It's not very clean, but it's functional.
On Thu, Mar 31, 2011 at 9:00 AM, thrillerbee thriller...@gmail.com wrote:
bump.
On Tue, Mar 29, 2011 at 11:27 AM, thrillerbee thriller...@gmail.comwrote:
Hopefully my last question:
Using append_branch() and $branch allows me to add all destinations as
branches with q-values. However, I am unable to remove/edit the initial
entry in $ds as set by do_routing():
Contact: *sip:15552345678@1.1.1.1, *sip:15552345678@1.1.1.1;q=1,
sip:2215552345678@2.2.2.2;q=0.9, sip:5552345678@3.3.3.3;q=0.85,
sip:15552345678@5.5.5.5;q=0.8, sip:sip:4415552345678@4.4.4.4;q=0.75
Is there a way to prevent do_routing from adding that entry and/or remove
it after it has been added? OR is there a way to add a q-value to that
instance?
Thanks,
Ryan
On Tue, Mar 29, 2011 at 10:51 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
Nevermind on that issue; I neglected to notice that I had to create the
branch with append_branch() before setting anything.
Thanks for the help.
Ryan
On Tue, Mar 29, 2011 at 9:52 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
When I configure:
$(branch(uri)[0]) = $ru;
$(branch(q)[0]) = 100;
xlog(L_INFO,branch 0 = $(branch(uri)[0]) with q-value
$(branch(q)[0])\n);
I get this debug:
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch
assigment [0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 163
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch
assigment [0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 164
branch 0 = null with q-value null
Thanks,
Ryan
On Tue, Mar 29, 2011 at 8:19 AM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
Hi,
Another tricks:
1) you can read the pending destinations directly from AVPs, without
calling the use_next_gw() function. See:
http://www.opensips.org/html/docs/modules/1.6.x/drouting.html#id293166
2) as append_branch() does not accept variables as params, use the
$branch variable to write into:
http://www.opensips.org/Resources/DocsCoreVar16#toc15
like:
$branch = $var(x) ; #add a new SIP URI as extra branch
$(branch(q)[-1]) = 10 ; # set Q val for the last added brach
Regards,
Bogdan
Anca Vamanu wrote:
Hi thrillerbe,
I think that if you only want to build the list of selected
destinations, you can just call use_next_gw and add the uri in RURI to a
destination string ( because use_next_gw sets the RURI to the
destination-
http://www.opensips.org/html/docs/modules/devel/drouting.html#id251519
).
It would be something like this:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ru\n); $var(x) = 2;
$var(ds) = $ru;
while (use_next_gw()) { $var(ds) =
$var(ds) + , + $ru;
xlog(L_INFO,After $var(x), ds is $var(ds)\n);
$var(x) = $var(x) + 1; } }
xlog(L_INFO,Destination
set is $var(ds)\n); }
Regards,
--
Anca Vamanu
OpenSIPS Developer
On 03/29/2011 01:00 AM, thrillerbee wrote:
I'm trying to get OpenSIPS to act as a REDIRECT server and have run
into a couple issues. I'm using the drouting module to do lookups.
Essentially, a dialed number could have potentially several routes, I
want
to return a 300 with these routes in the Contact header. Please tell me
if
this is foolish and/or there are better methods.
I'm running release version 1.6.4-2-notls.
With that, I've configured the following in my script:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) ==
2)
{
xlog(L_INFO,After 1, ds is $ds\n); $var(x) = 2;
while (use_next_gw()) { append_branch();
xlog(L_INFO,After $var(x), ds is $ds\n);
$var(x) = $var(x) + 1; } }
xlog(L_INFO,Destination set
is $ds\n); }
My relevant debug output is:
After 1, ds is Contact: sip:15552345678@1.1.1.1 mailto:
sip%3A15552345678@1.1.1.1 After 2, ds is Contact: *
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2*
After 3, ds is Contact: *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3* After 4, ds is Contact: *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5*,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:5552345678@3.3.3.3 mailto:sip%3A5552345678@3.3.3.3, *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5* After 5,
ds is Contact: *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3, sip
Re: [OpenSIPS-Users] drouting module with append_branch() and q-values
Bogdan,
When I configure:
$(branch(uri)[0]) = $ru;
$(branch(q)[0]) = 100;
xlog(L_INFO,branch 0 = $(branch(uri)[0]) with q-value
$(branch(q)[0])\n);
I get this debug:
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch assigment
[0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 163
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch assigment
[0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 164
branch 0 = null with q-value null
Thanks,
Ryan
On Tue, Mar 29, 2011 at 8:19 AM, Bogdan-Andrei Iancu bog...@opensips.orgwrote:
Hi,
Another tricks:
1) you can read the pending destinations directly from AVPs, without
calling the use_next_gw() function. See:
http://www.opensips.org/html/docs/modules/1.6.x/drouting.html#id293166
2) as append_branch() does not accept variables as params, use the
$branch variable to write into:
http://www.opensips.org/Resources/DocsCoreVar16#toc15
like:
$branch = $var(x) ; #add a new SIP URI as extra branch
$(branch(q)[-1]) = 10 ; # set Q val for the last added brach
Regards,
Bogdan
Anca Vamanu wrote:
Hi thrillerbe,
I think that if you only want to build the list of selected destinations,
you can just call use_next_gw and add the uri in RURI to a destination
string ( because use_next_gw sets the RURI to the destination-
http://www.opensips.org/html/docs/modules/devel/drouting.html#id251519).
It would be something like this:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ru\n); $var(x) = 2;
$var(ds) = $ru;
while (use_next_gw()) { $var(ds) = $var(ds) +
, + $ru;
xlog(L_INFO,After $var(x), ds is $var(ds)\n);
$var(x) = $var(x) + 1; } } xlog(L_INFO,Destination set
is $var(ds)\n); }
Regards,
--
Anca Vamanu
OpenSIPS Developer
On 03/29/2011 01:00 AM, thrillerbee wrote:
I'm trying to get OpenSIPS to act as a REDIRECT server and have run into
a couple issues. I'm using the drouting module to do lookups. Essentially, a
dialed number could have potentially several routes, I want to return a 300
with these routes in the Contact header. Please tell me if this is foolish
and/or there are better methods.
I'm running release version 1.6.4-2-notls.
With that, I've configured the following in my script:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ds\n); $var(x) = 2;
while (use_next_gw()) { append_branch();
xlog(L_INFO,After $var(x), ds is $ds\n);
$var(x) = $var(x) + 1; } } xlog(L_INFO,Destination set
is $ds\n); }
My relevant debug output is:
After 1, ds is Contact: sip:15552345678@1.1.1.1 mailto:
sip%3A15552345678@1.1.1.1 After 2, ds is Contact: *
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2* After 3,
ds is Contact: *sip:5552345678@3.3.3.3 mailto:sip%3A5552345678@3.3.3.3*,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2, *
sip:5552345678@3.3.3.3 mailto:sip%3A5552345678@3.3.3.3* After 4, ds is
Contact: *sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5*,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:5552345678@3.3.3.3 mailto:sip%3A5552345678@3.3.3.3, *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5* After 5, ds
is Contact: *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3, sip:15552345678@5.5.5.5 mailto:
sip%3A15552345678@5.5.5.5, *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*
It seems that append_branch() deletes the first entry in the destination
set before adding the current RURI to the beginning and end. Is there an
easier or more predictable way to write to the destination set?
Also, it seems the append_branch() function will not take variables or
avps as parameters. Is there a known way of setting different q-values as a
destination set is generated? The below obviously doesn't work but should
explain what I'm looking for:
var(q) = 90;
while (use_next_branch())
{
append_branch($ru,$var(q));
$var(q) = $var(q) - 10;
}
Thanks,
Ryan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and know-how
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] drouting module with append_branch() and q-values
Hopefully my last question:
Using append_branch() and $branch allows me to add all destinations as
branches with q-values. However, I am unable to remove/edit the initial
entry in $ds as set by do_routing():
Contact: *sip:15552345678@1.1.1.1, *sip:15552345678@1.1.1.1;q=1,
sip:2215552345678@2.2.2.2;q=0.9, sip:5552345678@3.3.3.3;q=0.85,
sip:15552345678@5.5.5.5;q=0.8, sip:sip:4415552345678@4.4.4.4;q=0.75
Is there a way to prevent do_routing from adding that entry and/or remove it
after it has been added? OR is there a way to add a q-value to that
instance?
Thanks,
Ryan
On Tue, Mar 29, 2011 at 10:51 AM, thrillerbee thriller...@gmail.com wrote:
Bogdan,
Nevermind on that issue; I neglected to notice that I had to create the
branch with append_branch() before setting anything.
Thanks for the help.
Ryan
On Tue, Mar 29, 2011 at 9:52 AM, thrillerbee thriller...@gmail.comwrote:
Bogdan,
When I configure:
$(branch(uri)[0]) = $ru;
$(branch(q)[0]) = 100;
xlog(L_INFO,branch 0 = $(branch(uri)[0]) with q-value
$(branch(q)[0])\n);
I get this debug:
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch assigment
[0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 163
ERROR:core:pv_set_branch_fields: SCRIPT BUG - inexisting branch assigment
[0/0]
ERROR:core:do_assign: setting PV failed
ERROR:core:do_assign: error at line: 164
branch 0 = null with q-value null
Thanks,
Ryan
On Tue, Mar 29, 2011 at 8:19 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:
Hi,
Another tricks:
1) you can read the pending destinations directly from AVPs, without
calling the use_next_gw() function. See:
http://www.opensips.org/html/docs/modules/1.6.x/drouting.html#id293166
2) as append_branch() does not accept variables as params, use the
$branch variable to write into:
http://www.opensips.org/Resources/DocsCoreVar16#toc15
like:
$branch = $var(x) ; #add a new SIP URI as extra branch
$(branch(q)[-1]) = 10 ; # set Q val for the last added brach
Regards,
Bogdan
Anca Vamanu wrote:
Hi thrillerbe,
I think that if you only want to build the list of selected
destinations, you can just call use_next_gw and add the uri in RURI to a
destination string ( because use_next_gw sets the RURI to the destination-
http://www.opensips.org/html/docs/modules/devel/drouting.html#id251519
).
It would be something like this:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ru\n); $var(x) = 2;
$var(ds) = $ru;
while (use_next_gw()) { $var(ds) = $var(ds)
+ , + $ru;
xlog(L_INFO,After $var(x), ds is $var(ds)\n);
$var(x) = $var(x) + 1; } } xlog(L_INFO,Destination
set is $var(ds)\n); }
Regards,
--
Anca Vamanu
OpenSIPS Developer
On 03/29/2011 01:00 AM, thrillerbee wrote:
I'm trying to get OpenSIPS to act as a REDIRECT server and have run
into a couple issues. I'm using the drouting module to do lookups.
Essentially, a dialed number could have potentially several routes, I want
to return a 300 with these routes in the Contact header. Please tell me if
this is foolish and/or there are better methods.
I'm running release version 1.6.4-2-notls.
With that, I've configured the following in my script:
if (do_routing(1,2)) { if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ds\n); $var(x) = 2;
while (use_next_gw()) { append_branch();
xlog(L_INFO,After $var(x), ds is $ds\n);
$var(x) = $var(x) + 1; } } xlog(L_INFO,Destination
set
is $ds\n); }
My relevant debug output is:
After 1, ds is Contact: sip:15552345678@1.1.1.1 mailto:
sip%3A15552345678@1.1.1.1 After 2, ds is Contact: *
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2* After
3, ds is Contact: *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, *sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3* After 4, ds is Contact: *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5*,
sip:2215552345678@2.2.2.2 mailto:sip%3A2215552345678@2.2.2.2,
sip:5552345678@3.3.3.3 mailto:sip%3A5552345678@3.3.3.3, *
sip:15552345678@5.5.5.5 mailto:sip%3A15552345678@5.5.5.5* After 5,
ds is Contact: *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*, sip:2215552345678@2.2.2.2 mailto:
sip%3A2215552345678@2.2.2.2, sip:5552345678@3.3.3.3 mailto:
sip%3A5552345678@3.3.3.3, sip:15552345678@5.5.5.5 mailto:
sip%3A15552345678@5.5.5.5, *sip:4415552345678@4.4.4.4 mailto:
sip%3A4415552345678@4.4.4.4*
It seems that append_branch() deletes the first entry in the
destination set before adding the current RURI to the beginning and end.
Is
there an easier or more predictable way to write
[OpenSIPS-Users] drouting module with append_branch() and q-values
I'm trying to get OpenSIPS to act as a REDIRECT server and have run into a
couple issues. I'm using the drouting module to do lookups. Essentially, a
dialed number could have potentially several routes, I want to return a 300
with these routes in the Contact header. Please tell me if this is foolish
and/or there are better methods.
I'm running release version 1.6.4-2-notls.
With that, I've configured the following in my script:
if (do_routing(1,2))
{
if ($avp(s:dr_rules_attrs) == 2)
{
xlog(L_INFO,After 1, ds is $ds\n);
$var(x) = 2;
while (use_next_gw())
{
append_branch();
xlog(L_INFO,After $var(x), ds is $ds\n);
$var(x) = $var(x) + 1;
}
}
xlog(L_INFO,Destination set is $ds\n);
}
My relevant debug output is:
After 1, ds is Contact: sip:15552345678@1.1.1.1
After 2, ds is Contact: *sip:2215552345678@2.2.2.2,
sip:2215552345678@2.2.2.2*
After 3, ds is Contact: *sip:5552345678@3.3.3.3*, sip:2215552345678@2.2.2.2,
*sip:5552345678@3.3.3.3*
After 4, ds is Contact: *sip:15552345678@5.5.5.5*, sip:2215552345678@2.2.2.2,
sip:5552345678@3.3.3.3, *sip:15552345678@5.5.5.5*
After 5, ds is Contact: *sip:4415552345678@4.4.4.4*,
sip:2215552345678@2.2.2.2, sip:5552345678@3.3.3.3, sip:15552345678@5.5.5.5,
*sip:4415552345678@4.4.4.4*
It seems that append_branch() deletes the first entry in the destination set
before adding the current RURI to the beginning and end. Is there an easier
or more predictable way to write to the destination set?
Also, it seems the append_branch() function will not take variables or avps
as parameters. Is there a known way of setting different q-values as a
destination set is generated? The below obviously doesn't work but should
explain what I'm looking for:
var(q) = 90;
while (use_next_branch())
{
append_branch($ru,$var(q));
$var(q) = $var(q) - 10;
}
Thanks,
Ryan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Reject INVITEs with invalid (unable to be parsed) headers
I'm really trying to find methods of combating memory leaks that I now believe must be caused by some specific traffic pattern. As a result, I'm trying to filter as much bad traffic as possible before it gets into the core of my network. I *have* seen parse errors on the from header as I use uac_replace_from to normalize traffic to determine jurisdiction, etc. I'd like to know how to identify that traffic, so, would $fu be NULL in this scenario? Is there a better method? Thanks. On Sun, Feb 13, 2011 at 7:13 AM, Tyler Merritt ty...@fonality.com wrote: I'm relatively new to OpenSIPs myself - but in my various experiments - the idea that OS cannot parse a header is a bit foreign. As a SIP proxy - it's job is more to use the routing logic in order to transmit packets from A through to C via B (OS itself). I have sent packets with bogus From and To headers and they transmit to the end destination just fine. I don't believe that your answer will be found in the format of the headers. Rather, the best way to detect invalid headers (I think) would be to use TextOps modules and REGEX to act on the headers themselves and detect formats that you say are valid. OS is flexible enough to do this - plenty of logic in the IF, THEN, ELSE statements within routing blocks in order to check these headers against rules that you assert are valid. On Sat, Feb 12, 2011 at 7:57 AM, thrillerbee thriller...@gmail.comwrote: What is the easiest way to identify traffic with invalid headers? Specifically, the from and to URIs. For example, if OpenSIPS is unable to parse a from URI, would $fu be NULL? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] b2bua top hiding module stripping from display name
Ovidiu, It is still stripping the from display name in the top hiding module. Running this version: URL: https://opensips.svn.sourceforge.net/svnroot/opensips/branches/1.6 Repository Root: https://opensips.svn.sourceforge.net/svnroot/opensips Repository UUID: 689a6050-402a-0410-94f2-e92a70836424 Revision: 7740 Node Kind: directory Schedule: normal Last Changed Author: anca_vamanu Last Changed Rev: 7740 Last Changed Date: 2011-02-14 16:30:59 + (Mon, 14 Feb 2011) Thanks, Ryan On Thu, Feb 3, 2011 at 7:49 PM, Ovidiu Sas o...@voipembedded.com wrote: Hello Ryan, Please try the latest version from trunk. Please test and report back. Regards, Ovidiu Sas On Thu, Feb 3, 2011 at 3:33 PM, thrillerbee thriller...@gmail.com wrote: Anca, Would it be possible to alter the built-in top hiding module so it doesn't strip the from display name? Thanks, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] b2bua top hiding module stripping from display name
doh... that did it. Thanks. On Mon, Feb 14, 2011 at 3:59 PM, Ovidiu Sas o...@voipembedded.com wrote: You need to use the trunk version. Regards, Ovidiu Sas On Mon, Feb 14, 2011 at 4:25 PM, thrillerbee thriller...@gmail.com wrote: Ovidiu, It is still stripping the from display name in the top hiding module. Running this version: URL: https://opensips.svn.sourceforge.net/svnroot/opensips/branches/1.6 Repository Root: https://opensips.svn.sourceforge.net/svnroot/opensips Repository UUID: 689a6050-402a-0410-94f2-e92a70836424 Revision: 7740 Node Kind: directory Schedule: normal Last Changed Author: anca_vamanu Last Changed Rev: 7740 Last Changed Date: 2011-02-14 16:30:59 + (Mon, 14 Feb 2011) Thanks, Ryan On Thu, Feb 3, 2011 at 7:49 PM, Ovidiu Sas o...@voipembedded.com wrote: Hello Ryan, Please try the latest version from trunk. Please test and report back. Regards, Ovidiu Sas On Thu, Feb 3, 2011 at 3:33 PM, thrillerbee thriller...@gmail.com wrote: Anca, Would it be possible to alter the built-in top hiding module so it doesn't strip the from display name? Thanks, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Reject INVITEs with invalid (unable to be parsed) headers
What is the easiest way to identify traffic with invalid headers? Specifically, the from and to URIs. For example, if OpenSIPS is unable to parse a from URI, would $fu be NULL? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] b2bua top hiding module stripping from display name
Anca, Would it be possible to alter the built-in top hiding module so it doesn't strip the from display name? Thanks, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] b2bua core dump db truncate
Anca,
I am still seeing core dumps on rev 7441 - it was up for about 5 min.
Backtrace attached.
Thanks.
On Sat, Nov 20, 2010 at 7:56 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
Can you please update - I have fixed on Friday a similar crash.
Regards,
Anca
On 19/11/10 16:43, thrillerbee wrote:
Anca,
Did you receive these backtraces?
Thanks.
On Mon, Nov 15, 2010 at 1:20 PM, thrillerbee thriller...@gmail.comwrote:
Anca,
I upgraded to rev 7383 and changed config to:
...
loadmodule b2b_entities.so
loadmodule b2b_logic.so
...
It crashed after about 15 minutes of moderate traffic. It actually
wrote 2 core files so I've attached both backtraces (first is *_e.txt,
second is *_2.txt).
Thanks again.
On Mon, Nov 15, 2010 at 11:44 AM, Anca Vamanu a...@opensips.org wrote:
They must be loaded in reverse order because b2b_logic depends on
b2b_entities - but it shouldn't crash, I will fix that.
Thanks also.
On 11/15/2010 07:41 PM, thrillerbee wrote:
Actually, yes, I have. Is that incorrect? I'll reverse the order
they're loaded test.
Thanks.
On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
Have you by any chance loaded the b2b_logic module before b2b_entities
module?
Regards,
Anca
On 11/14/2010 12:18 AM, thrillerbee wrote:
New core dump on rev 7371
Backtrace attached.
Thanks.
On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
You were right, sorry, I did a partial commit. It is now ok.
Regards,
Anca
--
Anca Vamanu
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing
listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Anca Vamanuwww.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
(gdb) bt
#0 0xb7304a1c in t_uac (method=0xb7286498, headers=0x0, body=0x0,
dialog=0x81a85d0, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
#1 0xb73062c3 in req_within (method=0xb7286498, headers=0x0, body=0x0,
dialog=0x81a85d0, completion_cb=0, cbp=0x0, release_func=0) at uac.c:396
#2 0xb7279340 in b2b_send_req (dlg=0x38dfc8f0, leg=0x81a850c,
method=0xb7286498, extra_headers=0x0) at dlg.c:1701
#3 0xb72803b6 in b2b_tm_cback (t=0x38d4db80, htable=0x37285f28, ps=0xb73108d4)
at dlg.c:1983
#4 0xb7273fd2 in b2b_client_tm_cback (t=0x38d4db80, type=512, ps=0xb73108d4)
at client.c:44
#5 0xb72eb924 in run_trans_callbacks (type=512, trans=0x38d4db80, req=0x0,
rpl=0x81a5088, code=200) at t_hooks.c:208
#6 0xb73026f6 in local_reply (t=0x38d4db80, p_msg=0x81a5088, branch=0,
msg_status=200, cancel_bitmap=0xbfd1a6e0) at t_reply.c:1350
#7 0xb7303a39 in reply_received (p_msg=0x81a5088) at t_reply.c:1495
#8 0x080678c2 in forward_reply (msg=0x81a5088) at forward.c:559
#9 0x080986bb in receive_msg (
buf=0x81783a0 SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
217.36.90.52;branch=z9hG4bKa672.4df87e96.0\r\nFrom:
sip:13053577...@8.20.212.240;tag=6d0a496ae253b92ea43eeacbb0d408bd\r\nTo:
sip:15055369...@67.228.15.154;tag=1cc81d203d...,
len=681, rcv_info=0xbfd1a804) at receive.c:200
#10 0x080d9ba4 in udp_rcv_loop () at udp_server.c:492
#11 0x0806ea79 in main (argc=9, argv=0xbfd1a9a4) at main.c:818
(gdb) bt full
#0 0xb7304a1c in t_uac (method=0xb7286498, headers=0x0, body=0x0,
dialog=0x81a85d0, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
to_su = {s = {sa_family = 2, sa_data =
\023#17\232\000\000\000\000\000\000\000}, sin = {sin_family = 2, sin_port
= 50195, sin_addr = {s_addr = 2584732739}, sin_zero =
\000\000\000\000\000\000\000}, sin6 = {
sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 2584732739, sin6_addr =
{in6_u = {u6_addr8 = '\0' repeats 15 times, u6_addr16 = {0, 0, 0, 0, 0, 0, 0,
0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}
new_cell = (struct cell *) 0x38612d50
backup = value optimized out
buf = value optimized out
buf1 = value optimized out
buf_len = value optimized out
buf_len1 = value optimized out
ret = value optimized out
flags = value optimized out
backup_route_type = value optimized out
hi = value optimized out
send_sock = value optimized out
req = (struct sip_msg *) 0x0
__FUNCTION__ = t_uac
#1 0xb73062c3 in req_within (method=0xb7286498, headers=0x0, body=0x0,
dialog=0x81a85d0, completion_cb=0, cbp=0x0, release_func=0) at uac.c:396
__FUNCTION__ = req_within
#2 0xb7279340 in b2b_send_req (dlg=0x38dfc8f0, leg=0x81a850c,
method=0xb7286498, extra_headers=0x0) at dlg.c:1701
td = (dlg_t *) 0x0
result = value optimized out
__FUNCTION__
Re: [OpenSIPS-Users] b2bua core dump db truncate
Anca, Did you receive these backtraces? Thanks. On Mon, Nov 15, 2010 at 1:20 PM, thrillerbee thriller...@gmail.com wrote: Anca, I upgraded to rev 7383 and changed config to: ... loadmodule b2b_entities.so loadmodule b2b_logic.so ... It crashed after about 15 minutes of moderate traffic. It actually wrote 2 core files so I've attached both backtraces (first is *_e.txt, second is *_2.txt). Thanks again. On Mon, Nov 15, 2010 at 11:44 AM, Anca Vamanu a...@opensips.org wrote: They must be loaded in reverse order because b2b_logic depends on b2b_entities - but it shouldn't crash, I will fix that. Thanks also. On 11/15/2010 07:41 PM, thrillerbee wrote: Actually, yes, I have. Is that incorrect? I'll reverse the order they're loaded test. Thanks. On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu a...@opensips.org wrote: Hi, Have you by any chance loaded the b2b_logic module before b2b_entities module? Regards, Anca On 11/14/2010 12:18 AM, thrillerbee wrote: New core dump on rev 7371 Backtrace attached. Thanks. On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu a...@opensips.org wrote: Hi, You were right, sorry, I did a partial commit. It is now ok. Regards, Anca -- Anca Vamanu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Anca Vamanuwww.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Anca Vamanuwww.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan, Are these memlogs useful? Please let me know if I can provide any other info. Thanks again. On Sat, Nov 13, 2010 at 4:20 PM, thrillerbee thriller...@gmail.com wrote: Bogdan, Since I made those changes, it doesn't core dump anymore - it just runs out of memory and stops processing packets. It happened on both of my proxies - the mem dump can be downloaded here: http://www.starviewconnect.com/tmp/core1_mem_dump_20101112.gz http://www.starviewconnect.com/tmp/core2_mem_dump_20101112.gz Thanks. On Thu, Nov 11, 2010 at 12:43 PM, thrillerbee thriller...@gmail.comwrote: Bogdan, I had already increased the PKG_MEM_POOL_SIZE by *10. I'm making the changes suggested in the link you provided to try to narrow down the memory issue. I'll send over as soon as I have another crash with mem info. Thanks. On Thu, Nov 11, 2010 at 5:10 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: This last crash had the same bt as the one from previous email ? the prev fix I made reports this: ERROR:db_flatstore:flat_db_insert: uninitialized connection and does not crash, so this time the crash may be in a different place. Now, it seams after all that the root of your problem is the mem exhaustion. To see what causes this (if a mem leak or simply not enough mem), there is a doc - http://www.opensips.org/Resources/DocsTsMem (it is for shm, but the same for pkg). Maybe, first you should simply try to increase the pkg mem ( in config.h you have PKG_MEM_POOL_SIZE that you can increase) - you NEED to recompile and reinstall after that. If more pkg mem does not solve the problem, I can help you with using the memory debugger to see what is going on there. Regards, Bogdan thrillerbee wrote: My other proxy crashed as well with these ERRORs in the syslog: Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:get_name: pkg memory allocation failure Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_reopen_connection: failed to get_name Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection ... Nov 10 22:01:21 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 22:01:22 core2 kernel: [4297088.404734] opensips[22959]: segfault at 10 ip 7f3db577e21f sp 7fffa260d640 error 4 in db_flatstore.so[7f3db577b000+5000] On Wed, Nov 10, 2010 at 10:19 AM, thrillerbee thriller...@gmail.commailto: thriller...@gmail.com wrote: Bogdan, Well, I spoke too soon - it's not just an issue with the opensipsctl fifo calls - looks more like a memory leak. It crashed again today, but I did get some errors in the syslog this time right before the crash: Nov 10 15:42:32 core1 /usr/local/sbin/opensips[27044]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 15:42:32 core1 kernel: [5508366.582447] opensips[27044]: segfault at 10 ip 7fa7ff74c21f sp 7fffdc101700 error 4 in db_flatstore.so[7fa7ff749000+5000] To be thorough, I've attached the backtrace output from print commands (although they're the same as before). To answer your question, yes - I do use the flat_rotate MI command. Thanks again. On Wed, Nov 10, 2010 at 4:04 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi, opensipsctl takes care that each command takes a separate fifo reply, so here it should be no problem. But the problem may be when comes with sending multiple commands (via FIFO) in the same time - this translates into parallel writes to the same file and depends on the atomicity of the write op. But in the worst case, a mixture at the FIFO level may lead to bogus command and not in any kind of crashDo you use the flat_rotate MI command ? Regards, Bogdan thrillerbee wrote: Bogdan, It seems the issue is with 'opensipsctl fifo' - it's very sensitive to simultaneous calls. Basically, I've combined all my scripts to prevent 'opensipsctl fifo' from being called too frequently and that seems (so far) to have mitigated the issue. Is there anything one should know about how (not) to use /opensipsctl/? Thanks. On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice
Re: [OpenSIPS-Users] OpenSIPS core dumps
John, I appreciate the suggestion, but, unfortunately, I don't use t_newtran(). What led you to remove that? Thanks, Ryan On Tue, Nov 16, 2010 at 9:08 AM, John Khvatov iva...@gmail.com wrote: Hello. On 10.11.2010, at 19:19, thrillerbee wrote: Well, I spoke too soon - it's not just an issue with the opensipsctl fifo calls - looks more like a memory leak. It crashed again today, but I did get some errors in the syslog this time right before the crash: Nov 10 15:42:32 core1 /usr/local/sbin/opensips[27044]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 15:42:32 core1 kernel: [5508366.582447] opensips[27044]: segfault at 10 ip 7fa7ff74c21f sp 7fffdc101700 error 4 in db_flatstore.so[7fa7ff749000+5000] To be thorough, I've attached the backtrace output from print commands (although they're the same as before). I have the same issue. OpenSIPS crashes at db_flatstore.so due to lack of memory (according resident memory usage graph). Recently I removed the use of the t_newtran() function and localstore module in opensips.cfg and crash did not happens for 11 days. Earlier crash happens every two-tree days. Do you use t_newtran() in your config? -- WBR, John Khvatov ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] b2bua core dump db truncate
Actually, yes, I have. Is that incorrect? I'll reverse the order they're loaded test. Thanks. On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu a...@opensips.org wrote: Hi, Have you by any chance loaded the b2b_logic module before b2b_entities module? Regards, Anca On 11/14/2010 12:18 AM, thrillerbee wrote: New core dump on rev 7371 Backtrace attached. Thanks. On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu a...@opensips.org wrote: Hi, You were right, sorry, I did a partial commit. It is now ok. Regards, Anca -- Anca Vamanu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Anca Vamanuwww.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] b2bua core dump db truncate
Anca,
I upgraded to rev 7383 and changed config to:
...
loadmodule b2b_entities.so
loadmodule b2b_logic.so
...
It crashed after about 15 minutes of moderate traffic. It actually wrote 2
core files so I've attached both backtraces (first is *_e.txt, second is
*_2.txt).
Thanks again.
On Mon, Nov 15, 2010 at 11:44 AM, Anca Vamanu a...@opensips.org wrote:
They must be loaded in reverse order because b2b_logic depends on
b2b_entities - but it shouldn't crash, I will fix that.
Thanks also.
On 11/15/2010 07:41 PM, thrillerbee wrote:
Actually, yes, I have. Is that incorrect? I'll reverse the order they're
loaded test.
Thanks.
On Mon, Nov 15, 2010 at 11:37 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
Have you by any chance loaded the b2b_logic module before b2b_entities
module?
Regards,
Anca
On 11/14/2010 12:18 AM, thrillerbee wrote:
New core dump on rev 7371
Backtrace attached.
Thanks.
On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
You were right, sorry, I did a partial commit. It is now ok.
Regards,
Anca
--
Anca Vamanu
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing
listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Anca Vamanuwww.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing
listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Anca Vamanuwww.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Core was generated by `/usr/local/sbin/opensips -P
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 23158]
#0 0xb72f5a1c in t_uac (method=0xb7277498, headers=0x0, body=0x0,
dialog=0x81a5b90, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
56 v=(*p24)+(p[1]16)+(p[2]8)+p[3];
(gdb) bt
#0 0xb72f5a1c in t_uac (method=0xb7277498, headers=0x0, body=0x0,
dialog=0x81a5b90, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
#1 0xb72f72c3 in req_within (method=0xb7277498, headers=0x0, body=0x0,
dialog=0x81a5b90, completion_cb=0, cbp=0x0, release_func=0) at uac.c:396
#2 0xb726a340 in b2b_send_req (dlg=0x3985d8dc, leg=0x81a576c,
method=0xb7277498, extra_headers=0x0) at dlg.c:1701
#3 0xb72713b6 in b2b_tm_cback (t=0x3c4db4f0, htable=0x37276efc, ps=0xb73018d4)
at dlg.c:1983
#4 0xb7264fd2 in b2b_client_tm_cback (t=0x3c4db4f0, type=512, ps=0xb73018d4)
at client.c:44
#5 0xb72dc924 in run_trans_callbacks (type=512, trans=0x3c4db4f0, req=0x0,
rpl=0x81a5088, code=200) at t_hooks.c:208
#6 0xb72f36f6 in local_reply (t=0x3c4db4f0, p_msg=0x81a5088, branch=0,
msg_status=200, cancel_bitmap=0xbfc09c80) at t_reply.c:1348
#7 0xb72f4a39 in reply_received (p_msg=0x81a5088) at t_reply.c:1493
#8 0x080678c2 in forward_reply (msg=0x81a5088) at forward.c:559
#9 0x080986bb in receive_msg (
buf=0x81783a0 SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
207.36.90.52;branch=z9hG4bK7bad.deb109c1.0\r\nContact:
sip:18454928...@64.79.131.132:5060\r\nTo:
sip:18454928...@64.79.131.132;tag=58dcb4ae-co6123-INS001\r\nFrom: sip:1...,
len=654, rcv_info=0xbfc09da4) at receive.c:200
#10 0x080d9ba4 in udp_rcv_loop () at udp_server.c:492
#11 0x0806ea79 in main (argc=9, argv=0xbfc09f44) at main.c:818
(gdb) bt full
#0 0xb72f5a1c in t_uac (method=0xb7277498, headers=0x0, body=0x0,
dialog=0x81a5b90, cb=0, cbp=0x0, release_func=0) at ../../mem/../hash_func.h:56
to_su = {s = {sa_family = 2, sa_data =
\023##O\203\204\000\000\000\000\000\000\000}, sin = {sin_family = 2, sin_port
= 50195, sin_addr = {s_addr = 2223198016},
sin_zero = \000\000\000\000\000\000\000}, sin6 = {sin6_family = 2,
sin6_port = 50195, sin6_flowinfo = 2223198016, sin6_addr = {in6_u = {
u6_addr8 = '\0' repeats 15 times, u6_addr16 = {0, 0, 0, 0, 0, 0, 0,
0}, u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}
new_cell = (struct cell *) 0x3d2473a0
backup = value optimized out
buf = value optimized out
buf1 = value optimized out
buf_len = value optimized out
buf_len1 = value optimized out
ret = value optimized out
flags = value optimized out
backup_route_type = value optimized out
hi = value optimized out
send_sock = value optimized out
req = (struct sip_msg *) 0x0
__FUNCTION__ = t_uac
#1 0xb72f72c3 in req_within (method=0xb7277498, headers=0x0, body=0x0,
dialog=0x81a5b90, completion_cb=0, cbp
Re: [OpenSIPS-Users] b2bua core dump db truncate
New core dump on rev 7371
Backtrace attached.
Thanks.
On Thu, Nov 11, 2010 at 4:41 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
You were right, sorry, I did a partial commit. It is now ok.
Regards,
Anca
--
Anca Vamanu
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Core was generated by `/usr/local/sbin/opensips -P
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 8731]
#0 0xb712f8e5 in b2b_search_htable (table=0x0, hash_index=155,
local_index=3481) at dlg.c:141
141 dlg= table[hash_index].first;
(gdb) bt full
#0 0xb712f8e5 in b2b_search_htable (table=0x0, hash_index=155,
local_index=3481) at dlg.c:141
dlg = value optimized out
__FUNCTION__ = b2b_search_htable
#1 0xb71235db in b2b_restore_logic_info (type=B2B_SERVER, key=0xbf89bf80,
cback=0xb728cf3c b2b_server_notify) at b2b_entities.c:357
dlg = value optimized out
table = (b2b_table) 0x0
hash_index = 155
local_index = 3481
__FUNCTION__ = b2b_restore_logic_info
#2 0xb7280a0c in b2b_logic_restore () at b2b_logic.c:1213
i = 0
nr_rows = 12
result = (db_res_t *) 0x819df68
rows = (db_row_t *) 0x81a4310
row_vals = value optimized out
tuple = {id = 0, key = 0xbf89c0b0, scenario = 0x0, scenario_params =
{{s = 0x99b80ad , len = 0}, {s = 0x99b80ae , len = 0}, {
s = 0x99b80af , len = 0}, {s = 0x99b80b0 , len = 0}, {s = 0x99b80b1
, len = 0}}, scenario_state = -3, next_scenario_state = 0,
server = 0x0, clients = 0x0, bridge_entities = {0xbf89bf78, 0xbf89bfb0,
0xbf89bfe8}, to_del = 0, extra_headers = 0x0, next = 0x0, prev = 0x0,
insert_time = 0, lifetime = 0, sdp = {s = 0x99b80b2 , len = 0}, db_flag = 0}
b2bl_key = {s = 0x99b80a0 1789.0, len = 6}
scenario_id = {s = 0x99b80a7 , len = 0}
bridge_entities = {{scenario_id = {s = 0x99b80b5 , len = 0}, key = {s
= 0x99b80f6 B2B.155.3481, len = 12}, to_uri = {
s = 0x99b80b6 sip:244517062375...@66.234.136.133, len = 34}, from_uri =
{s = 0x99b80d9 sip:9375592...@207.2.123.187, len = 28},
dlginfo = 0x0, disconnected = 0, state = 0, type = B2B_SERVER, next = 0x0,
peer = 0x0}, {scenario_id = {s = 0x99b8105 , len = 0}, key = {
s = 0x99b8146 B2B.1789.7511494, len = 16}, to_uri = {s = 0x99b8106
sip:244517062375...@66.234.136.133, len = 34}, from_uri = {
s = 0x99b8129 sip:9375592...@207.2.123.187, len = 28}, dlginfo = 0x0,
disconnected = 0, state = 0, type = B2B_CLIENT, next = 0x0,
peer = 0x0}, {scenario_id = {s = 0x99b8157 , len = 0}, key = {s =
0x99b815a , len = 0}, to_uri = {s = 0x99b8158 , len = 0},
from_uri = {s = 0x99b8159 , len = 0}, dlginfo = 0x0, disconnected = 0,
state = 0, type = 3076297573, next = 0x0, peer = 0x0}}
params = {0xbf89c02c, 0xbf89c034, 0xbf89c03c, 0xbf89c044, 0xbf89c04c}
result_cols = {0xb7294340, 0xb7294348, 0xb7294380, 0xb7294388,
0xb7294350, 0xb7294358, 0xb7294360, 0xb7294368, 0xb7294370, 0xb7294378,
0xb7294390, 0xb7294398, 0xb72943a0, 0xb72943a8, 0xb72943b0, 0xb72943b8,
0xb72943c0, 0xb72943c8, 0xb72943d0, 0xb72943d8, 0xb72943e0,
0xb72943e8, 0xb72943f0, 0xb72943f8, 0xb7294400}
__FUNCTION__ = b2b_logic_restore
---Type return to continue, or q return to quit---
#3 0xb7281aff in mod_init () at b2b_logic.c:252
p = value optimized out
i = value optimized out
j = value optimized out
__FUNCTION__ = mod_init
#4 0x080b781c in init_mod (m=0x819ee38) at sr_module.c:457
__FUNCTION__ = init_mod
#5 0x080b77b8 in init_mod (m=0x819eee0) at sr_module.c:452
__FUNCTION__ = init_mod
#6 0x0806e1cb in main (argc=9, argv=0xbf89c2a4) at main.c:1351
cfg_log_stderr = 0
cfg_stream = (FILE *) 0x9998008
c = value optimized out
r = value optimized out
tmp = 0xbf89cea4
tmp_len = value optimized out
port = value optimized out
proto = value optimized out
ret = value optimized out
seed = 2146665141
rfd = value optimized out
__FUNCTION__ = main
(gdb) ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan, Since I made those changes, it doesn't core dump anymore - it just runs out of memory and stops processing packets. It happened on both of my proxies - the mem dump can be downloaded here: http://www.starviewconnect.com/tmp/core1_mem_dump_20101112.gz http://www.starviewconnect.com/tmp/core2_mem_dump_20101112.gz Thanks. On Thu, Nov 11, 2010 at 12:43 PM, thrillerbee thriller...@gmail.com wrote: Bogdan, I had already increased the PKG_MEM_POOL_SIZE by *10. I'm making the changes suggested in the link you provided to try to narrow down the memory issue. I'll send over as soon as I have another crash with mem info. Thanks. On Thu, Nov 11, 2010 at 5:10 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: This last crash had the same bt as the one from previous email ? the prev fix I made reports this: ERROR:db_flatstore:flat_db_insert: uninitialized connection and does not crash, so this time the crash may be in a different place. Now, it seams after all that the root of your problem is the mem exhaustion. To see what causes this (if a mem leak or simply not enough mem), there is a doc - http://www.opensips.org/Resources/DocsTsMem (it is for shm, but the same for pkg). Maybe, first you should simply try to increase the pkg mem ( in config.h you have PKG_MEM_POOL_SIZE that you can increase) - you NEED to recompile and reinstall after that. If more pkg mem does not solve the problem, I can help you with using the memory debugger to see what is going on there. Regards, Bogdan thrillerbee wrote: My other proxy crashed as well with these ERRORs in the syslog: Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:get_name: pkg memory allocation failure Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_reopen_connection: failed to get_name Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection ... Nov 10 22:01:21 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 22:01:22 core2 kernel: [4297088.404734] opensips[22959]: segfault at 10 ip 7f3db577e21f sp 7fffa260d640 error 4 in db_flatstore.so[7f3db577b000+5000] On Wed, Nov 10, 2010 at 10:19 AM, thrillerbee thriller...@gmail.commailto: thriller...@gmail.com wrote: Bogdan, Well, I spoke too soon - it's not just an issue with the opensipsctl fifo calls - looks more like a memory leak. It crashed again today, but I did get some errors in the syslog this time right before the crash: Nov 10 15:42:32 core1 /usr/local/sbin/opensips[27044]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 15:42:32 core1 kernel: [5508366.582447] opensips[27044]: segfault at 10 ip 7fa7ff74c21f sp 7fffdc101700 error 4 in db_flatstore.so[7fa7ff749000+5000] To be thorough, I've attached the backtrace output from print commands (although they're the same as before). To answer your question, yes - I do use the flat_rotate MI command. Thanks again. On Wed, Nov 10, 2010 at 4:04 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi, opensipsctl takes care that each command takes a separate fifo reply, so here it should be no problem. But the problem may be when comes with sending multiple commands (via FIFO) in the same time - this translates into parallel writes to the same file and depends on the atomicity of the write op. But in the worst case, a mixture at the FIFO level may lead to bogus command and not in any kind of crashDo you use the flat_rotate MI command ? Regards, Bogdan thrillerbee wrote: Bogdan, It seems the issue is with 'opensipsctl fifo' - it's very sensitive to simultaneous calls. Basically, I've combined all my scripts to prevent 'opensipsctl fifo' from being called too frequently and that seems (so far) to have mitigated the issue. Is there anything one should know about how (not) to use /opensipsctl/? Thanks. On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi, strange if you do not have any errors :( I just made a fix on both trunk and 1.6 to extend some checks
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan, I had already increased the PKG_MEM_POOL_SIZE by *10. I'm making the changes suggested in the link you provided to try to narrow down the memory issue. I'll send over as soon as I have another crash with mem info. Thanks. On Thu, Nov 11, 2010 at 5:10 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: This last crash had the same bt as the one from previous email ? the prev fix I made reports this: ERROR:db_flatstore:flat_db_insert: uninitialized connection and does not crash, so this time the crash may be in a different place. Now, it seams after all that the root of your problem is the mem exhaustion. To see what causes this (if a mem leak or simply not enough mem), there is a doc - http://www.opensips.org/Resources/DocsTsMem (it is for shm, but the same for pkg). Maybe, first you should simply try to increase the pkg mem ( in config.h you have PKG_MEM_POOL_SIZE that you can increase) - you NEED to recompile and reinstall after that. If more pkg mem does not solve the problem, I can help you with using the memory debugger to see what is going on there. Regards, Bogdan thrillerbee wrote: My other proxy crashed as well with these ERRORs in the syslog: Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:get_name: pkg memory allocation failure Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_reopen_connection: failed to get_name Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection ... Nov 10 22:01:21 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 22:01:22 core2 kernel: [4297088.404734] opensips[22959]: segfault at 10 ip 7f3db577e21f sp 7fffa260d640 error 4 in db_flatstore.so[7f3db577b000+5000] On Wed, Nov 10, 2010 at 10:19 AM, thrillerbee thriller...@gmail.commailto: thriller...@gmail.com wrote: Bogdan, Well, I spoke too soon - it's not just an issue with the opensipsctl fifo calls - looks more like a memory leak. It crashed again today, but I did get some errors in the syslog this time right before the crash: Nov 10 15:42:32 core1 /usr/local/sbin/opensips[27044]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 15:42:32 core1 kernel: [5508366.582447] opensips[27044]: segfault at 10 ip 7fa7ff74c21f sp 7fffdc101700 error 4 in db_flatstore.so[7fa7ff749000+5000] To be thorough, I've attached the backtrace output from print commands (although they're the same as before). To answer your question, yes - I do use the flat_rotate MI command. Thanks again. On Wed, Nov 10, 2010 at 4:04 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi, opensipsctl takes care that each command takes a separate fifo reply, so here it should be no problem. But the problem may be when comes with sending multiple commands (via FIFO) in the same time - this translates into parallel writes to the same file and depends on the atomicity of the write op. But in the worst case, a mixture at the FIFO level may lead to bogus command and not in any kind of crashDo you use the flat_rotate MI command ? Regards, Bogdan thrillerbee wrote: Bogdan, It seems the issue is with 'opensipsctl fifo' - it's very sensitive to simultaneous calls. Basically, I've combined all my scripts to prevent 'opensipsctl fifo' from being called too frequently and that seems (so far) to have mitigated the issue. Is there anything one should know about how (not) to use /opensipsctl/? Thanks. On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi, strange if you do not have any errors :( I just made a fix on both trunk and 1.6 to extend some checks in flatstore and prevent crashing (even if the DB op will not be executed). Could you update from SVN and see if stops crashing ? Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan,
Well, I spoke too soon - it's not just an issue with the opensipsctl fifo
calls - looks more like a memory leak. It crashed again today, but I did
get some errors in the syslog this time right before the crash:
Nov 10 15:42:32 core1 /usr/local/sbin/opensips[27044]:
ERROR:db_flatstore:new_flat_id: no pkg memory left
Nov 10 15:42:32 core1 kernel: [5508366.582447] opensips[27044]: segfault at
10 ip 7fa7ff74c21f sp 7fffdc101700 error 4 in
db_flatstore.so[7fa7ff749000+5000]
To be thorough, I've attached the backtrace output from print commands
(although they're the same as before).
To answer your question, yes - I do use the flat_rotate MI command.
Thanks again.
On Wed, Nov 10, 2010 at 4:04 AM, Bogdan-Andrei Iancu bog...@voice-system.ro
wrote:
Hi,
opensipsctl takes care that each command takes a separate fifo reply, so
here it should be no problem. But the problem may be when comes with sending
multiple commands (via FIFO) in the same time - this translates into
parallel writes to the same file and depends on the atomicity of the write
op.
But in the worst case, a mixture at the FIFO level may lead to bogus
command and not in any kind of crashDo you use the flat_rotate MI
command ?
Regards,
Bogdan
thrillerbee wrote:
Bogdan,
It seems the issue is with 'opensipsctl fifo' - it's very sensitive to
simultaneous calls. Basically, I've combined all my scripts to prevent
'opensipsctl fifo' from being called too frequently and that seems (so far)
to have mitigated the issue. Is there anything one should know about how
(not) to use /opensipsctl/?
Thanks.
On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro wrote:
Hi,
strange if you do not have any errors :(
I just made a fix on both trunk and 1.6 to extend some checks in
flatstore and prevent crashing (even if the DB op will not be
executed).
Could you update from SVN and see if stops crashing ?
Regards,
Bogdan
Core was generated by `/usr/local/sbin/opensips -P
/var/run/opensips/opensips.pid -m 512 -u root -g ro'.
Program terminated with signal 11, Segmentation fault.
[New process 27044]
#0 0x7fa7ff74c21f in flat_db_insert (h=0x7efb38, k=0x7fa7fe48ca60,
v=0x7fa7fe48cd20, n=19) at flatstore.c:165
165 f = CON_FILE(h);
(gdb) bt full
#0 0x7fa7ff74c21f in flat_db_insert (h=0x7efb38, k=0x7fa7fe48ca60,
v=0x7fa7fe48cd20, n=19) at flatstore.c:165
f = value optimized out
i = value optimized out
l = value optimized out
p = value optimized out
__FUNCTION__ = flat_db_insert
#1 0x7fa7fe2737ef in acc_db_request (rq=0x7fa7de27a978, rpl=value
optimized out) at acc.c:364
m = 19
n = value optimized out
i = value optimized out
my_ps = (db_ps_t) 0x0
__FUNCTION__ = acc_db_request
#2 0x7fa7fe27869e in tmcb_func (t=value optimized out, type=value
optimized out, ps=value optimized out) at acc_logic.c:386
No locals.
#3 0x7fa7ff1014a2 in run_trans_callbacks (type=256, trans=0x7fa7df8a6e00,
req=0x7fa7de27a978, rpl=0x7efef0, code=200) at t_hooks.c:208
cbp = (struct tm_callback *) 0x7fa7dc84f6f0
backup = (struct usr_avp **) 0x771f48
trans_backup = (struct cell *) 0x7fa7df8a6e00
__FUNCTION__ = run_trans_callbacks
#4 0x7fa7ff1015c7 in run_trans_callbacks_locked (type=256,
trans=0x7fa7df8a6e00, req=0x7fa7de27a978, rpl=0x7efef0, code=200) at
t_hooks.c:254
No locals.
#5 0x7fa7ff11ea38 in relay_reply (t=0x7fa7df8a6e00, p_msg=value optimized
out, branch=1, msg_status=200, cancel_bitmap=0x7fffdc101ad8) at t_reply.c:1257
relay = 1
save_clone = 0
buf = 0x1184390 SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
24.121.80.36;branch=z9hG4bKadcb.35a7dc2.0\r\nVia: SIP/2.0/UDP
184.106.205.223;branch=z9hG4bKadcb.be5e7083.0\r\nVia: SIP/2.0/UDP
216.18.222.3;branch=z9hG4bKadcb.18d6b484.0\r...
res_len = 1391
relayed_code = 200
relayed_msg = (struct sip_msg *) 0x7efef0
bm = {to_tag_val = {s = 0x1 Address 0x1 out of bounds, len = 8322800}}
totag_retr = value optimized out
reply_status = RPS_COMPLETED
cb_s = {
s = 0x1184390 SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
24.121.80.36;branch=z9hG4bKadcb.35a7dc2.0\r\nVia: SIP/2.0/UDP
184.106.205.223;branch=z9hG4bKadcb.be5e7083.0\r\nVia: SIP/2.0/UDP
216.18.222.3;branch=z9hG4bKadcb.18d6b484.0\r..., len = 1391}
text = {s = 0x18f Address 0x18f out of bounds, len = 1452}
__FUNCTION__ = relay_reply
#6 0x7fa7ff11f548 in reply_received (p_msg=0x7efef0) at t_reply.c:1502
last_uac_status = value optimized out
branch = 1
reply_status = value optimized out
timer = value optimized out
cancel_bitmap = 0
t = (struct cell *) 0x7fa7df8a6e00
backup_list = value optimized out
has_reply_route = 3692375232
__FUNCTION__ = reply_received
Re: [OpenSIPS-Users] b2bua core dump db truncate
Anca, The b2b_logic module will not compile: make[1]: Entering directory `/usr/local/src/opensips_1_6/modules/b2b_logic' Compiling b2b_logic.c gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott -Wold-style-definition -Wmissing-field-initializers -Wredundant-decls -DMOD_NAME='b2b_logic'-DNAME='opensips' -DVERSION='1.6.3-notls' -DARCH='i386' -DOS='linux' -DCOMPILER='gcc 4.3.2' -D__CPU_i386 -D__OS_linux -D__SMP_yes -DCFG_DIR='/usr/local/etc/opensips/' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='2:7361' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -I/usr/include/libxml2 -I/usr/local/include/libxml2 -I/usr/local/include -c b2b_logic.c -o b2b_logic.o Compiling logic.c gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott -Wold-style-definition -Wmissing-field-initializers -Wredundant-decls -DMOD_NAME='b2b_logic'-DNAME='opensips' -DVERSION='1.6.3-notls' -DARCH='i386' -DOS='linux' -DCOMPILER='gcc 4.3.2' -D__CPU_i386 -D__OS_linux -D__SMP_yes -DCFG_DIR='/usr/local/etc/opensips/' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='2:7361' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -I/usr/include/libxml2 -I/usr/local/include/libxml2 -I/usr/local/include -c logic.c -o logic.o logic.c: In function ‘process_bridge_bye’: logic.c:352: warning: passing argument 4 of ‘b2b_api.send_reply’ makes integer from pointer without a cast logic.c:352: warning: passing argument 7 of ‘b2b_api.send_reply’ from incompatible pointer type logic.c:352: error: too few arguments to function ‘b2b_api.send_reply’ logic.c: In function ‘b2b_logic_notify’: logic.c:780: warning: passing argument 4 of ‘b2b_api.send_reply’ makes integer from pointer without a cast logic.c:780: warning: passing argument 7 of ‘b2b_api.send_reply’ from incompatible pointer type logic.c:780: error: too few arguments to function ‘b2b_api.send_reply’ logic.c:848: warning: passing argument 4 of ‘b2b_api.send_reply’ makes integer from pointer without a cast logic.c:848: warning: passing argument 7 of ‘b2b_api.send_reply’ from incompatible pointer type logic.c:848: error: too few arguments to function ‘b2b_api.send_reply’ logic.c:851: warning: passing argument 4 of ‘b2b_api.send_reply’ makes integer from pointer without a cast logic.c:851: warning: passing argument 7 of ‘b2b_api.send_reply’ from incompatible pointer type logic.c:851: error: too few arguments to function ‘b2b_api.send_reply’ logic.c:857: warning: passing argument 4 of ‘b2b_api.send_reply’ makes integer from pointer without a cast logic.c:857: warning: passing argument 7 of ‘b2b_api.send_reply’ from incompatible pointer type logic.c:857: error: too few arguments to function ‘b2b_api.send_reply’ logic.c:1052: warning: passing argument 4 of ‘b2b_api.send_reply’ makes integer from pointer without a cast logic.c:1052: warning: passing argument 7 of ‘b2b_api.send_reply’ from incompatible pointer type logic.c:1052: error: too few arguments to function ‘b2b_api.send_reply’ make[1]: *** [logic.o] Error 1 make[1]: Leaving directory `/usr/local/src/opensips_1_6/modules/b2b_logic' make: *** [modules] Error 2 Regards. On Wed, Nov 10, 2010 at 6:10 AM, Anca Vamanu a...@opensips.org wrote: Hi, I have found the cause of the crash and fixed it. Please update your code. Thanks and regards, -- Anca Vamanuwww.voice-system.ro On 11/09/2010 06:40 PM, thrillerbee wrote: Anca, I am seeing a crash about every 13-14 days. I've attached the backtrace from this morning. The other problem is that OpenSIPS immediately crashes when monit tries to restart it. I have to manually truncate the b2b_entities b2b_logic tables to get it to start w/o crashing. I'm attaching this backtrace as well (called *restart*). Thanks. On Mon, Nov 1, 2010 at 10:56 AM, thrillerbee thriller...@gmail.comwrote: Anca, I had not altered the code. It core dumped pretty quickly so I was force to revert to revision 7317. I will try to schedule some time to retest the newest revision and see if it core dumps again. Thanks again. On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu a...@opensips.org wrote: Hi, The lines in your gdb backtrace don't match at all. Have you altered the code or is the core corrupted? Regards, -- Anca Vamanuwww.voice-system.ro
Re: [OpenSIPS-Users] OpenSIPS core dumps
My other proxy crashed as well with these ERRORs in the syslog: Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:get_name: pkg memory allocation failure Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_reopen_connection: failed to get_name Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:02 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection ... Nov 10 22:01:21 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:flat_db_insert: uninitialized connection Nov 10 22:01:22 core2 /usr/local/sbin/opensips[22959]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 22:01:22 core2 kernel: [4297088.404734] opensips[22959]: segfault at 10 ip 7f3db577e21f sp 7fffa260d640 error 4 in db_flatstore.so[7f3db577b000+5000] On Wed, Nov 10, 2010 at 10:19 AM, thrillerbee thriller...@gmail.com wrote: Bogdan, Well, I spoke too soon - it's not just an issue with the opensipsctl fifo calls - looks more like a memory leak. It crashed again today, but I did get some errors in the syslog this time right before the crash: Nov 10 15:42:32 core1 /usr/local/sbin/opensips[27044]: ERROR:db_flatstore:new_flat_id: no pkg memory left Nov 10 15:42:32 core1 kernel: [5508366.582447] opensips[27044]: segfault at 10 ip 7fa7ff74c21f sp 7fffdc101700 error 4 in db_flatstore.so[7fa7ff749000+5000] To be thorough, I've attached the backtrace output from print commands (although they're the same as before). To answer your question, yes - I do use the flat_rotate MI command. Thanks again. On Wed, Nov 10, 2010 at 4:04 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi, opensipsctl takes care that each command takes a separate fifo reply, so here it should be no problem. But the problem may be when comes with sending multiple commands (via FIFO) in the same time - this translates into parallel writes to the same file and depends on the atomicity of the write op. But in the worst case, a mixture at the FIFO level may lead to bogus command and not in any kind of crashDo you use the flat_rotate MI command ? Regards, Bogdan thrillerbee wrote: Bogdan, It seems the issue is with 'opensipsctl fifo' - it's very sensitive to simultaneous calls. Basically, I've combined all my scripts to prevent 'opensipsctl fifo' from being called too frequently and that seems (so far) to have mitigated the issue. Is there anything one should know about how (not) to use /opensipsctl/? Thanks. On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi, strange if you do not have any errors :( I just made a fix on both trunk and 1.6 to extend some checks in flatstore and prevent crashing (even if the DB op will not be executed). Could you update from SVN and see if stops crashing ? Regards, Bogdan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan, It seems the issue is with 'opensipsctl fifo' - it's very sensitive to simultaneous calls. Basically, I've combined all my scripts to prevent 'opensipsctl fifo' from being called too frequently and that seems (so far) to have mitigated the issue. Is there anything one should know about how (not) to use *opensipsctl*? Thanks. On Mon, Nov 8, 2010 at 6:07 AM, Bogdan-Andrei Iancu bog...@voice-system.rowrote: Hi, strange if you do not have any errors :( I just made a fix on both trunk and 1.6 to extend some checks in flatstore and prevent crashing (even if the DB op will not be executed). Could you update from SVN and see if stops crashing ? Regards, Bogdan thrillerbee wrote: Bogdan, I am not seeing any other errors in the logs. Is there anything else I can look at? Both proxies are crashing everyday. Thanks. On Wed, Nov 3, 2010 at 4:21 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: I got some clue about what is happening - as you are using flatstore for acc, the acc module does not check the success of the use_table DB operation - in 90% of the cases (for mysql, postgres, etc) this function cannot fail, but it seams that for flatstore can. And if it fails, the h-tail is set to NULL, leading to crash. Now, before the crash itself, do you see any other ERROR messages (even long before the crash) related to flatstore module ? Try: grep ERROR opensips_log_file | grep flatstore Regards, Bogdan thrillerbee wrote: Bogdan, One more detail that may help - I added another OpenSIPS proxy in parallel with this one ( load balancing between the two) and now both OpenSIPS proxies crash at the same time (within a couple seconds). I can provide more core dumps if it will help. Thanks. On Tue, Nov 2, 2010 at 9:02 AM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com wrote: Bogdan, Below is the info requested: (gdb) frame 0 #0 0x7f51999f221f in flat_db_insert (h=0x7f0978, k=0x7f5198732a60, v=0x7f5198732d20, n=19) at flatstore.c:165 165 f = CON_FILE(h); (gdb) print h $1 = (const db_con_t *) 0x7f0978 (gdb) print h-tail $2 = 0 (gdb) print ((struct flat_con*)(h-tail))-file Cannot access memory at address 0x10 Before each of the crashes yesterday, I saw these in the logs: Nov 1 14:17:40 core1 kernel: [4287745.452111] opensips[22141]: segfault at 10 ip 7f51999f221f sp 7fffbcd8d510 error 4 in db_flatstore.so[7f51999ef000+5000] Nov 1 23:52:58 core1 kernel: [4348562.990735] opensips[26978]: segfault at 10 ip 7f726cb9b21f sp 7083f6f0 error 4 in db_flatstore.so[7f726cb98000+5000] Are there any compiler flags I should use for debugging? (gdb) info locals f = value optimized out i = value optimized out l = value optimized out p = value optimized out __FUNCTION__ = flat_db_insert Thanks again. On Tue, Nov 2, 2010 at 4:18 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi, in frame 0, could you print: h h-tail ((struct flat_con*)(h-tail))-file Also, before crash, do you see in the logs any errors from the db_flatstore module ? Regards, Bogdan thrillerbee wrote: Bogdan, It crashed again tonight. I've attached the backtrace. Thanks. On Mon, Nov 1, 2010 at 9:32 AM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com wrote: Bogdan, Yes, I've attached 2 to my response - one was a crash from 10/29. The other occurred a few minutes ago. Thanks. On Fri, Oct 22, 2010 at 11:41 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice
Re: [OpenSIPS-Users] b2bua core dump db truncate
Anca,
I am seeing a crash about every 13-14 days. I've attached the backtrace
from this morning.
The other problem is that OpenSIPS immediately crashes when monit tries to
restart it. I have to manually truncate the b2b_entities b2b_logic tables
to get it to start w/o crashing. I'm attaching this backtrace as well
(called *restart*).
Thanks.
On Mon, Nov 1, 2010 at 10:56 AM, thrillerbee thriller...@gmail.com wrote:
Anca,
I had not altered the code. It core dumped pretty quickly so I was force
to revert to revision 7317.
I will try to schedule some time to retest the newest revision and see if
it core dumps again.
Thanks again.
On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
The lines in your gdb backtrace don't match at all. Have you altered the
code or is the core corrupted?
Regards,
--
Anca Vamanuwww.voice-system.ro
On 11/01/2010 04:35 PM, thrillerbee wrote:
Anca,
I am still seeing core dumps. bt attached.
Thanks .
On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee thriller...@gmail.comwrote:
Anca,
Thanks for the info. I'll let you know if I have issues after the
upgrade.
Thanks.
On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
At startup, the b2b_tables are copied into memory and are truncated,
then the data is updated in the database at an interval controlled by
the update_period parameter ( by default 100 seconds).
As for the core dump, if you are using trunk, can you please update your
code? I just committed a lot of changes in those modules.
Regards,
--
Anca Vamanu
www.voice-system.ro
On 10/26/2010 06:58 AM, thrillerbee wrote:
I'm waiting for my b2bua box to core dump again so I can get the
backtrace, but is it expected behavior that OpenSIPS cannot restart
w/o first truncating the b2b_entities b2b_logic tables? That makes
for a messy recovery...
Thanks.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing
listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Core was generated by `/usr/local/sbin/opensips -P
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 12409]
#0 t_unref_cell (c=0x0) at t_lookup.c:1169
1169UNREF(c);
(gdb) bt full
#0 t_unref_cell (c=0x0) at t_lookup.c:1169
__FUNCTION__ = t_unref_cell
#1 0x7fe9774ec9e1 in b2b_prescript_f (msg=0x799e88, uparam=value
optimized out) at dlg.c:488
reason = {s = 0x7fe9774f58c0 OK, len = 2}
b2b_key = {s = 0x799e88 s len = 1}
dlg = value optimized out
hash_index = value optimized out
local_index = value optimized out
b2b_cback = value optimized out
param = {s = 0x0, len = 0}
table = value optimized out
method_value = value optimized out
TO = {error = 7741452, body = {s = 0xa Address 0xa out of bounds, len
= 0}, uri = {s = 0x7fe90006 , len = 0}, display = {
s = 0x762066 38794...@68.68.124.33;tag=gK0b7076d4\r\nTo:
sip:2482000...@24.121.80.36;tag=B2B.2482.3343\r\nCall-ID:
772517652_72287...@68.68.124.33\r\ncseq: 12225 PRACK\r\nMax-Forwards:
68\r\nRAck: 113 12224 INVITE\r\nConte..., len = 70}, tag_value = {s =
0x56b00497f81 Address 0x56b00497f81 out of bounds, len = 0}, parsed_uri =
{user = {
s = 0x761fac 121.80.39;branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom:
sip:+13138794...@68.68..., len = 510}, passwd = {
s = 0x761fb6 branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom:
sip:+13138794...@68.68.124.33;t..., len = 98}, host = {s = 0x4d5ba9
H\211D$XH\205##\017#T$0D\213\\$(\017\204###, len = 59}, port = {
s = 0x4cc929 h\21...@h\205##\213t$\030l\213\\$\020\017\204###, len =
7741335}, params = {s = 0x7fffc7331f78 ###, len = 7741337}, headers = {s =
0x0,
len = 1963685894}, port_no = 27160, proto = 124, type = ERROR_URI_T,
transport = {s = 0x76213e , len = 7741341}, ttl = {
s = 0x761fb6 branch=z9hG4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r\nFrom:
sip:+13138794...@68.68.124.33;t..., len = 8005424}, user_param = {
s = 0x761fc1 4bKaeec.ed9119a4.0\r\nVia: SIP/2.0/UDP
24.121.80.36;branch=z9hG4bKaeec.5a7bedb.0\r\nVia: SIP/2.0/UDP
68.68.124.33:5060;branch=z9hG4bK0bB84d6261f073b06b6\r
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan, I am not seeing any other errors in the logs. Is there anything else I can look at? Both proxies are crashing everyday. Thanks. On Wed, Nov 3, 2010 at 4:21 AM, Bogdan-Andrei Iancu bog...@voice-system.rowrote: I got some clue about what is happening - as you are using flatstore for acc, the acc module does not check the success of the use_table DB operation - in 90% of the cases (for mysql, postgres, etc) this function cannot fail, but it seams that for flatstore can. And if it fails, the h-tail is set to NULL, leading to crash. Now, before the crash itself, do you see any other ERROR messages (even long before the crash) related to flatstore module ? Try: grep ERROR opensips_log_file | grep flatstore Regards, Bogdan thrillerbee wrote: Bogdan, One more detail that may help - I added another OpenSIPS proxy in parallel with this one ( load balancing between the two) and now both OpenSIPS proxies crash at the same time (within a couple seconds). I can provide more core dumps if it will help. Thanks. On Tue, Nov 2, 2010 at 9:02 AM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com wrote: Bogdan, Below is the info requested: (gdb) frame 0 #0 0x7f51999f221f in flat_db_insert (h=0x7f0978, k=0x7f5198732a60, v=0x7f5198732d20, n=19) at flatstore.c:165 165 f = CON_FILE(h); (gdb) print h $1 = (const db_con_t *) 0x7f0978 (gdb) print h-tail $2 = 0 (gdb) print ((struct flat_con*)(h-tail))-file Cannot access memory at address 0x10 Before each of the crashes yesterday, I saw these in the logs: Nov 1 14:17:40 core1 kernel: [4287745.452111] opensips[22141]: segfault at 10 ip 7f51999f221f sp 7fffbcd8d510 error 4 in db_flatstore.so[7f51999ef000+5000] Nov 1 23:52:58 core1 kernel: [4348562.990735] opensips[26978]: segfault at 10 ip 7f726cb9b21f sp 7083f6f0 error 4 in db_flatstore.so[7f726cb98000+5000] Are there any compiler flags I should use for debugging? (gdb) info locals f = value optimized out i = value optimized out l = value optimized out p = value optimized out __FUNCTION__ = flat_db_insert Thanks again. On Tue, Nov 2, 2010 at 4:18 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi, in frame 0, could you print: h h-tail ((struct flat_con*)(h-tail))-file Also, before crash, do you see in the logs any errors from the db_flatstore module ? Regards, Bogdan thrillerbee wrote: Bogdan, It crashed again tonight. I've attached the backtrace. Thanks. On Mon, Nov 1, 2010 at 9:32 AM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com wrote: Bogdan, Yes, I've attached 2 to my response - one was a crash from 10/29. The other occurred a few minutes ago. Thanks. On Fri, Oct 22, 2010 at 11:41 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Any chance with the backtraces ? Regards, Bogdan Anca Vamanu wrote: Hi, You need to inspect them with gdb, run: gdb path_to_opensips_executable path_to_corefile, and then run 'bt full' and send the output. Regards, -- Anca Vamanu www.voice-system.ro http://www.voice-system.ro http://www.voice-system.ro On 10/14/2010 10:12 PM, thrillerbee wrote: I have this info from dmesg: [1985853.285221] opensips[30865]: segfault at 10 ip 7f43899ce21f sp 7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000] [1985856.379671] opensips[30858]: segfault at 10 ip 7f43899ce21f sp 7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000] [1985896.961279] opensips[30868]: segfault at 10 ip 7f43899ce21f sp 7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan, One more detail that may help - I added another OpenSIPS proxy in parallel with this one ( load balancing between the two) and now both OpenSIPS proxies crash at the same time (within a couple seconds). I can provide more core dumps if it will help. Thanks. On Tue, Nov 2, 2010 at 9:02 AM, thrillerbee thriller...@gmail.com wrote: Bogdan, Below is the info requested: (gdb) frame 0 #0 0x7f51999f221f in flat_db_insert (h=0x7f0978, k=0x7f5198732a60, v=0x7f5198732d20, n=19) at flatstore.c:165 165 f = CON_FILE(h); (gdb) print h $1 = (const db_con_t *) 0x7f0978 (gdb) print h-tail $2 = 0 (gdb) print ((struct flat_con*)(h-tail))-file Cannot access memory at address 0x10 Before each of the crashes yesterday, I saw these in the logs: Nov 1 14:17:40 core1 kernel: [4287745.452111] opensips[22141]: segfault at 10 ip 7f51999f221f sp 7fffbcd8d510 error 4 in db_flatstore.so[7f51999ef000+5000] Nov 1 23:52:58 core1 kernel: [4348562.990735] opensips[26978]: segfault at 10 ip 7f726cb9b21f sp 7083f6f0 error 4 in db_flatstore.so[7f726cb98000+5000] Are there any compiler flags I should use for debugging? (gdb) info locals f = value optimized out i = value optimized out l = value optimized out p = value optimized out __FUNCTION__ = flat_db_insert Thanks again. On Tue, Nov 2, 2010 at 4:18 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi, in frame 0, could you print: h h-tail ((struct flat_con*)(h-tail))-file Also, before crash, do you see in the logs any errors from the db_flatstore module ? Regards, Bogdan thrillerbee wrote: Bogdan, It crashed again tonight. I've attached the backtrace. Thanks. On Mon, Nov 1, 2010 at 9:32 AM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com wrote: Bogdan, Yes, I've attached 2 to my response - one was a crash from 10/29. The other occurred a few minutes ago. Thanks. On Fri, Oct 22, 2010 at 11:41 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Any chance with the backtraces ? Regards, Bogdan Anca Vamanu wrote: Hi, You need to inspect them with gdb, run: gdb path_to_opensips_executable path_to_corefile, and then run 'bt full' and send the output. Regards, -- Anca Vamanu www.voice-system.ro http://www.voice-system.ro On 10/14/2010 10:12 PM, thrillerbee wrote: I have this info from dmesg: [1985853.285221] opensips[30865]: segfault at 10 ip 7f43899ce21f sp 7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000] [1985856.379671] opensips[30858]: segfault at 10 ip 7f43899ce21f sp 7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000] [1985896.961279] opensips[30868]: segfault at 10 ip 7f43899ce21f sp 7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000] [2000131.245512] opensips[17672]: segfault at 10 ip 7fd0f21fb21f sp 7fff3a3b4f00 error 4 in db_flatstore.so[7fd0f21f8000+5000] [2000161.735962] opensips[17668]: segfault at 10 ip 7fd0f21fb21f sp 7fff3a3b4e40 error 4 in db_flatstore.so[7fd0f21f8000+5000] [2000167.299402] opensips[17670]: segfault at 10 ip 7fd0f21fb21f sp 7fff3a3b4f00 error 4 in db_flatstore.so[7fd0f21f8000+5000] On Thu, Oct 14, 2010 at 1:57 PM, thrillerbee thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com mailto:thriller...@gmail.com wrote: When OpenSIPS crashes, three corefiles are generated that are 2.1GB in size. How do I use these files to understand what's causing the crash? Thanks. ___ Users mailing list Users@lists.opensips.org mailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro http://www.voice-system.ro ___ Users mailing list Users@lists.opensips.org mailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan,
Yes, I've attached 2 to my response - one was a crash from 10/29. The
other occurred a few minutes ago.
Thanks.
On Fri, Oct 22, 2010 at 11:41 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Any chance with the backtraces ?
Regards,
Bogdan
Anca Vamanu wrote:
Hi,
You need to inspect them with gdb, run: gdb
path_to_opensips_executable path_to_corefile, and then run 'bt full'
and send the output.
Regards,
--
Anca Vamanu
www.voice-system.ro
On 10/14/2010 10:12 PM, thrillerbee wrote:
I have this info from dmesg:
[1985853.285221] opensips[30865]: segfault at 10 ip 7f43899ce21f sp
7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000]
[1985856.379671] opensips[30858]: segfault at 10 ip 7f43899ce21f sp
7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000]
[1985896.961279] opensips[30868]: segfault at 10 ip 7f43899ce21f sp
7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000]
[2000131.245512] opensips[17672]: segfault at 10 ip 7fd0f21fb21f sp
7fff3a3b4f00 error 4 in db_flatstore.so[7fd0f21f8000+5000]
[2000161.735962] opensips[17668]: segfault at 10 ip 7fd0f21fb21f sp
7fff3a3b4e40 error 4 in db_flatstore.so[7fd0f21f8000+5000]
[2000167.299402] opensips[17670]: segfault at 10 ip 7fd0f21fb21f sp
7fff3a3b4f00 error 4 in db_flatstore.so[7fd0f21f8000+5000]
On Thu, Oct 14, 2010 at 1:57 PM, thrillerbee thriller...@gmail.com
mailto:thriller...@gmail.com wrote:
When OpenSIPS crashes, three corefiles are generated that are
2.1GB in size. How do I use these files to understand what's
causing the crash?
Thanks.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Core was generated by `/usr/local/sbin/opensips -P
/var/run/opensips/opensips.pid -m 512 -u root -g ro'.
Program terminated with signal 11, Segmentation fault.
[New process 22242]
#0 0x7f66e354821f in flat_db_insert (h=0x7ea710, k=0x7f66e2288a60,
v=0x7f66e2288d20, n=19) at flatstore.c:165
165 f = CON_FILE(h);
(gdb) bt full
#0 0x7f66e354821f in flat_db_insert (h=0x7ea710, k=0x7f66e2288a60,
v=0x7f66e2288d20, n=19) at flatstore.c:165
f = value optimized out
i = value optimized out
l = value optimized out
p = value optimized out
__FUNCTION__ = flat_db_insert
#1 0x7f66e206f7ef in acc_db_request (rq=0x7f66c34266b8, rpl=value
optimized out) at acc.c:364
m = 19
n = value optimized out
i = value optimized out
my_ps = (db_ps_t) 0x0
__FUNCTION__ = acc_db_request
#2 0x7f66e207469e in tmcb_func (t=value optimized out, type=value
optimized out, ps=value optimized out) at acc_logic.c:386
No locals.
#3 0x7f66e2efd4a2 in run_trans_callbacks (type=256, trans=0x7f66c314eba0,
req=0x7f66c34266b8, rpl=0x7eaac8, code=200) at t_hooks.c:208
cbp = (struct tm_callback *) 0x7f66c1892ac8
backup = (struct usr_avp **) 0x771f48
trans_backup = (struct cell *) 0x7f66c314eba0
__FUNCTION__ = run_trans_callbacks
#4 0x7f66e2efd5c7 in run_trans_callbacks_locked (type=256,
trans=0x7f66c314eba0, req=0x7f66c34266b8, rpl=0x7eaac8, code=200) at
t_hooks.c:254
No locals.
#5 0x7f66e2f1aa38 in relay_reply (t=0x7f66c314eba0, p_msg=value optimized
out, branch=1, msg_status=200, cancel_bitmap=0x7fff3aa31ca8) at t_reply.c:1257
relay = 1
save_clone = 0
buf = 0x11846d0 SIP/2.0 200 OK\r\nRecord-Route:
sip:24.121.80.38;lr;ftag=gK075a5ad6;did=d9.c581cf61\r\nRecord-Route:
sip:24.121.80.36;lr;ftag=gK075a5ad6\r\nVia: SIP/2.0/UDP
24.121.80.36;branch=z9hG4bK13cd.038ec486.0\r\nV...
res_len = 685
relayed_code = 200
relayed_msg = (struct sip_msg *) 0x7eaac8
bm = {to_tag_val = {s = 0x1 Address 0x1 out of bounds, len = 8301256}}
totag_retr = value optimized out
reply_status = RPS_COMPLETED
cb_s = {
s = 0x11846d0 SIP/2.0 200 OK\r\nRecord-Route:
sip:24.121.80.38;lr;ftag=gK075a5ad6;did=d9.c581cf61\r\nRecord-Route:
sip:24.121.80.36;lr;ftag=gK075a5ad6\r\nVia: SIP/2.0/UDP
24.121.80.36;branch=z9hG4bK13cd.038ec486.0\r\nV..., len = 685}
text = {s = 0x16c Address 0x16c out of bounds, len = 746}
__FUNCTION__ = relay_reply
#6 0x7f66e2f1b548 in reply_received (p_msg=0x7eaac8) at t_reply.c:1502
last_uac_status = value optimized out
branch = 1
reply_status = value optimized out
timer = value optimized out
cancel_bitmap = 0
t = (struct cell
Re: [OpenSIPS-Users] b2bua core dump db truncate
Anca,
I am still seeing core dumps. bt attached.
Thanks.
On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee thriller...@gmail.com wrote:
Anca,
Thanks for the info. I'll let you know if I have issues after the upgrade.
Thanks.
On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu a...@opensips.org wrote:
Hi,
At startup, the b2b_tables are copied into memory and are truncated,
then the data is updated in the database at an interval controlled by
the update_period parameter ( by default 100 seconds).
As for the core dump, if you are using trunk, can you please update your
code? I just committed a lot of changes in those modules.
Regards,
--
Anca Vamanu
www.voice-system.ro
On 10/26/2010 06:58 AM, thrillerbee wrote:
I'm waiting for my b2bua box to core dump again so I can get the
backtrace, but is it expected behavior that OpenSIPS cannot restart
w/o first truncating the b2b_entities b2b_logic tables? That makes
for a messy recovery...
Thanks.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Core was generated by `/usr/local/sbin/opensips -P
/var/run/opensips/opensips.pid -m 2048 -u root -g r'.
Program terminated with signal 11, Segmentation fault.
[New process 10170]
#0 0x7f77f488e343 in t_uac (method=0x7f77f3676c90, headers=0x0, body=0x0,
dialog=0x7a5890, cb=0, cbp=0x0, release_func=0) at uac.c:287
287 LM_DBG(building sip_msg from buffer\n);
(gdb) bt full
#0 0x7f77f488e343 in t_uac (method=0x7f77f3676c90, headers=0x0, body=0x0,
dialog=0x7a5890, cb=0, cbp=0x0, release_func=0) at uac.c:287
to_su = {s = {sa_family = 2, sa_data =
\023##XB\n\000\000\000\000\000\000\000}, sin = {sin_family = 2, sin_port =
50195, sin_addr = {s_addr = 172120272},
sin_zero = \000\000\000\000\000\000\000}, sin6 = {sin6_family = 2,
sin6_port = 50195, sin6_flowinfo = 172120272, sin6_addr = {in6_u = {u6_addr8 =
'\0' repeats 15 times,
u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, u6_addr32 = {0, 0, 0, 0}}},
sin6_scope_id = 0}}
new_cell = (struct cell *) 0x7f7773b6a250
backup = value optimized out
buf = 0x0
buf1 = value optimized out
buf_len = value optimized out
buf_len1 = value optimized out
ret = value optimized out
flags = value optimized out
backup_route_type = value optimized out
hi = value optimized out
send_sock = value optimized out
req = (struct sip_msg *) 0x0
__FUNCTION__ = t_uac
#1 0x7f77f3468dc5 in b2b_tm_cback (t=value optimized out, htable=0xc8,
ps=0x7a5418) at dlg.c:1724
hash_index = 32767
local_index = 4246031144
b2b_cback = (b2b_notify_t) 0x7a5418 mem_pool+133368
dlg = (b2b_dlg_t *) 0x38
param = {s = 0x79a178 , len = 7971888}
statuscode = 32631
leg = value optimized out
pto = value optimized out
TO = {error = 56, body = {s = 0x744548 ###rw\177, len = 7970440}, uri
= {s = 0x7f77f34702c1 Address 0x7f77f34702c1 out of bounds, len = 0}, display
= {s = 0x793fe0 \002,
len = 2}, tag_value = {s = 0x0, len = 7970440}, parsed_uri = {user = {s =
0x7f7772ede400 , len = 1940377152}, passwd = {s = 0x7f77f39e87b9 , len =
1949299264}, host = {
s = 0xc800794030 Address 0xc800794030 out of bounds, len = 4}, port =
{s = 0x0, len = 7970440}, params = {s = 0x479dfb ##11##, len = 2},
headers = {s = 0x794080 \001,
len = 3}, port_no = 0, proto = 0, type = ERROR_URI_T, transport = {s =
0x799e88 \205`, len = 4693460}, ttl = {s = 0x2 Address 0x2 out of bounds,
len = 7926528}, user_param = {
s = 0x7944a8 \017, len = 14}, maddr = {s = 0xfffb Address
0xfffb out of bounds, len = 7970440}, method = {s = 0x12 Address 0x12 out
of bounds, len = 7741483}, lr = {
s = 0x3b Address 0x3b out of bounds, len = 5032233}, r2 = {s = 0x799e88
\205`, len = 7926528}, transport_val = {
s = 0x76202b
tion/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed\r\nRequire:
timer\r\nSupported: timer\r\nAllow:
INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTI...,
len = 7741600}, ttl_val = {s = 0x1 Address 0x1 out of bounds, len =
7994120}, user_param_val = {
s = 0xdfd154db0 Address 0xdfd154db0 out of bounds, len = 0}, maddr_val
= {s = 0x0, len = 7994176}, method_val = {
s = 0x76203f
/isup,application/dtmf,application/dtmf-relay,multipart/mixed\r\nRequire:
timer\r\nSupported: timer\r\nAllow:
INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH\r...,
len = 7741600}, lr_val = {s = 0x3 Address 0x3 out of bounds, len = 4957221},
r2_val = {s = 0x0, len = 7918344}}, param_lst = 0x7a3558,
last_param = 0x78d308}
to_tag = {
s = 0x761fcd 4-4cc6f5be-af15dbeb-5967ee57\r\nCall-ID:
B2B.1847.1171930\r\nCSeq: 3717657 INVITE\r\nAccept
Re: [OpenSIPS-Users] b2bua core dump db truncate
Anca, I had not altered the code. It core dumped pretty quickly so I was force to revert to revision 7317. I will try to schedule some time to retest the newest revision and see if it core dumps again. Thanks again. On Mon, Nov 1, 2010 at 10:44 AM, Anca Vamanu a...@opensips.org wrote: Hi, The lines in your gdb backtrace don't match at all. Have you altered the code or is the core corrupted? Regards, -- Anca Vamanuwww.voice-system.ro On 11/01/2010 04:35 PM, thrillerbee wrote: Anca, I am still seeing core dumps. bt attached. Thanks . On Tue, Oct 26, 2010 at 8:44 AM, thrillerbee thriller...@gmail.comwrote: Anca, Thanks for the info. I'll let you know if I have issues after the upgrade. Thanks. On Tue, Oct 26, 2010 at 3:42 AM, Anca Vamanu a...@opensips.org wrote: Hi, At startup, the b2b_tables are copied into memory and are truncated, then the data is updated in the database at an interval controlled by the update_period parameter ( by default 100 seconds). As for the core dump, if you are using trunk, can you please update your code? I just committed a lot of changes in those modules. Regards, -- Anca Vamanu www.voice-system.ro On 10/26/2010 06:58 AM, thrillerbee wrote: I'm waiting for my b2bua box to core dump again so I can get the backtrace, but is it expected behavior that OpenSIPS cannot restart w/o first truncating the b2b_entities b2b_logic tables? That makes for a messy recovery... Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing listus...@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS core dumps
Bogdan,
It crashed again tonight. I've attached the backtrace.
Thanks.
On Mon, Nov 1, 2010 at 9:32 AM, thrillerbee thriller...@gmail.com wrote:
Bogdan,
Yes, I've attached 2 to my response - one was a crash from 10/29. The
other occurred a few minutes ago.
Thanks.
On Fri, Oct 22, 2010 at 11:41 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Any chance with the backtraces ?
Regards,
Bogdan
Anca Vamanu wrote:
Hi,
You need to inspect them with gdb, run: gdb
path_to_opensips_executable path_to_corefile, and then run 'bt full'
and send the output.
Regards,
--
Anca Vamanu
www.voice-system.ro
On 10/14/2010 10:12 PM, thrillerbee wrote:
I have this info from dmesg:
[1985853.285221] opensips[30865]: segfault at 10 ip 7f43899ce21f sp
7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000]
[1985856.379671] opensips[30858]: segfault at 10 ip 7f43899ce21f sp
7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000]
[1985896.961279] opensips[30868]: segfault at 10 ip 7f43899ce21f sp
7fff8de1cf40 error 4 in db_flatstore.so[7f43899cb000+5000]
[2000131.245512] opensips[17672]: segfault at 10 ip 7fd0f21fb21f sp
7fff3a3b4f00 error 4 in db_flatstore.so[7fd0f21f8000+5000]
[2000161.735962] opensips[17668]: segfault at 10 ip 7fd0f21fb21f sp
7fff3a3b4e40 error 4 in db_flatstore.so[7fd0f21f8000+5000]
[2000167.299402] opensips[17670]: segfault at 10 ip 7fd0f21fb21f sp
7fff3a3b4f00 error 4 in db_flatstore.so[7fd0f21f8000+5000]
On Thu, Oct 14, 2010 at 1:57 PM, thrillerbee thriller...@gmail.com
mailto:thriller...@gmail.com wrote:
When OpenSIPS crashes, three corefiles are generated that are
2.1GB in size. How do I use these files to understand what's
causing the crash?
Thanks.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Core was generated by `/usr/local/sbin/opensips -P
/var/run/opensips/opensips.pid -m 512 -u root -g ro'.
Program terminated with signal 11, Segmentation fault.
[New process 26978]
#0 0x7f726cb9b21f in flat_db_insert (h=0x7f09a8, k=0x7f726b8dba60,
v=0x7f726b8dbd20, n=19) at flatstore.c:165
165 f = CON_FILE(h);
(gdb) bt full
#0 0x7f726cb9b21f in flat_db_insert (h=0x7f09a8, k=0x7f726b8dba60,
v=0x7f726b8dbd20, n=19) at flatstore.c:165
f = value optimized out
i = value optimized out
l = value optimized out
p = value optimized out
__FUNCTION__ = flat_db_insert
#1 0x7f726b6c27ef in acc_db_request (rq=0x7f726c77f160, rpl=value
optimized out) at acc.c:364
m = 19
n = value optimized out
i = value optimized out
my_ps = (db_ps_t) 0x0
__FUNCTION__ = acc_db_request
#2 0x7f726b6c7e28 in tmcb_func (t=0x7f724cea4fd8, type=value optimized
out, ps=0x4ccf5229) at acc_logic.c:319
No locals.
#3 0x7f726c5504a2 in run_trans_callbacks (type=64, trans=0x7f724cea4fd8,
req=0x7f726c77f160, rpl=0x7f0d60, code=404) at t_hooks.c:208
cbp = (struct tm_callback *) 0x7f724ab5c220
backup = (struct usr_avp **) 0x7f724cea6808
trans_backup = (struct cell *) 0x7f724cea4fd8
__FUNCTION__ = run_trans_callbacks
#4 0x7f726c56c9b4 in t_should_relay_response (Trans=0x7f724cea4fd8,
new_code=value optimized out, branch=1, should_store=0x7083fa18,
should_relay=0x7083fa1c, cancel_bitmap=0x7083fae8, reply=0x7f0d60)
at t_reply.c:611
branch_cnt = 2
inv_through = value optimized out
do_cancel = value optimized out
__FUNCTION__ = t_should_relay_response
#5 0x7f726c56cfe2 in relay_reply (t=0x7f09a8, p_msg=0x7f0d60,
branch=1288655401, msg_status=404, cancel_bitmap=0x7083fae8)
at t_reply.c:1133
relay = value optimized out
save_clone = value optimized out
buf = value optimized out
res_len = 0
relayed_code = 404
relayed_msg = value optimized out
bm = {to_tag_val = {s = 0x1 Address 0x1 out of bounds, len = 8326496}}
totag_retr = value optimized out
reply_status = value optimized out
cb_s = {
s = 0x76202d From: \Office\
sip:14064263...@8.20.212.252;tag=Uvyr85XQ8FNvj\r\nTo:
sip:30201#16606592...@24.121.80.36;tag=B2B.2064.650\r\nCall-ID:
91b97e04-f697-4827-bc02-d76b56b579b5\r\nCSeq: 3991724 INVITE\r\nContact...,
len = 8187368}
text = {
s = 0x76206e To:
sip:30201#16606592...@24.121.80.36;tag=B2B.2064.650\r\nCall-ID:
91b97e04-f697-4827-bc02-d76b56b579b5\r\nCSeq: 3991724 INVITE\r\nContact
Re: [OpenSIPS-Users] Two OpenSIPS one database
Stefano, Yes, when you specify the db_url, it doesn't have to be local. So multiple OpenSIPS instances can all pull from the same db if you want. That being said, how are you wanting to round robin? On Tue, Oct 26, 2010 at 3:42 PM, Stefano Pisani stefano.pis...@omnianet.itwrote: Hello, is it possible to share the database beteween two opensips? I would to use round robin to divide the load on more servers. Thanks s ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] dispatcher use_default
I've run into an issue when trying to utilize the use_default modparam for the dispatcher module. My understanding is that it would reserve the last entry in the setid as a failover gateway. Otherwise, it would treat all other gateways according to their weight. In reality, it seems that, if there are 3 gateways, the 2nd is used exclusively. If the 2nd gw is moved to an 'inactive' state, the 1st gateway is then used exclusively. As expected, if 1 2 go down the 3rd is finally used. Why aren't gw 1 2 statelessly load balanced like they would be if use_default was disabled? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] b2bua core dump db truncate
I'm waiting for my b2bua box to core dump again so I can get the backtrace, but is it expected behavior that OpenSIPS cannot restart w/o first truncating the b2b_entities b2b_logic tables? That makes for a messy recovery... Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dispatcher failover re-enabling with probing
Thank you!
I'll give that a shot report back.
Ryan
On Fri, Oct 22, 2010 at 12:07 PM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi,
what group are you using for your destination (in dispatcher) ? if 0,
use another one :D...there is an issue there...
Regards,
Bogdan
thrillerbee wrote:
I could still use some help on understanding what I'm missing that is
preventing gws from transitioning back into the 'active' state from
'probing'. Currently, I have to babysit this OpenSIPS instance.
Again, to summarize, when dispatcher detects a failure, it puts the gw
into 'probing' state begins sending OPTIONS messages to the failed
gw. Even though the gateway begins replying with 200s, dispatcher
never returns it to an 'active' state. I have to restart OpenSIPS to
return it to an 'active' state.
Here are the relevant pieces of my config script:
# - dispatcher params -
modparam(dispatcher, flags, 2)
modparam(dispatcher, dst_avp, $avp(i:271))
modparam(dispatcher, attrs_avp, $avp(i:272))
modparam(dispatcher, grp_avp, $avp(i:273))
modparam(dispatcher, cnt_avp, $avp(i:274))
modparam(dispatcher, ds_ping_interval, 1)
modparam(dispatcher, ds_probing_threshhold, 32)
modparam(dispatcher, ds_probing_mode, 0)
modparam(dispatcher, options_reply_codes, 501, 403, 200)
failure_route[1]
{
if (t_was_cancelled()) {
exit;
}
if ((t_check_status(408)) (t_local_replied(last)))
{
xlog(L_ERR,Gateway Failure! $ci\n);
ds_mark_dst(p);
t_on_failure(1);
t_relay();
}
}
Again, any assistance would be greatly appreciated.
Thanks.
On Mon, Oct 18, 2010 at 7:31 AM, thrillerbee thriller...@gmail.com
mailto:thriller...@gmail.com wrote:
Anca,
I have configured the ds_probing_threshold parameter which allows
me to adjust when I gw goes from active to probing.
However, my issue is getting the gw back to active. For some
reason, it will never transition back - even with successful 200
OK responses to the OPTIONS messages that are triggered when a gw
goes to probing. The examples below show that I can't even
force it back to active from probing to active with MI commands -
I have to restart OpenSIPS.
Thanks.
On Mon, Oct 18, 2010 at 5:50 AM, Anca Vamanu a...@opensips.org
mailto:a...@opensips.org wrote:
Hi Thrillerbee,
You can try to adjust the time when a gateway state is
changed into probing by setting the ds_probing_threshhold ||
parameter
(
http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id250525).
Regards,
--
Anca Vamanu
www.voice-system.ro http://www.voice-system.ro
On 10/16/2010 08:01 AM, thrillerbee wrote:
I have been able to get the dispatcher module to detect a gw
failure and put it into a probing state route traffic
elsewhere. However, when the gw returns ( begins responding
to OPTIONS with 200s), dispatcher never puts it back in the
active state.
In fact, I cannot even manually put the server back in the
active state with mi functions. I can put it in an inactive
state, but it returns to probing if I try to set it to active:
ogw1:~# opensipsctl fifo ds_list
SET_NO:: 1
SET:: 0
URI:: sip:12.121.80.38 flag=P
URI:: sip:12.121.80.39 flag=A
URI:: sip:12.121.80.40 flag=A
ogw1:~# opensipsctl fifo ds_set_state i 0 sip:12.121.80.38
ogw1:~# opensipsctl fifo ds_list
SET_NO:: 1
SET:: 0
URI:: sip:12.121.80.38 flag=I
URI:: sip:12.121.80.39 flag=A
URI:: sip:12.121.80.40 flag=A
ogw1:~# opensipsctl fifo ds_set_state a 0 sip:12.121.80.38
ogw1:~# opensipsctl fifo ds_list
SET_NO:: 1
SET:: 0
URI:: sip:12.121.80.38 flag=P
URI:: sip:12.121.80.39 flag=A
URI:: sip:12.121.80.40 flag=A
Is there some setting that I am missing that allows gateways
to transition from probing to active?
Thanks.
___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dispatcher failover re-enabling with probing
Bogan,
That resolved it. Thanks for the advice.
Ryan
On Fri, Oct 22, 2010 at 12:32 PM, thrillerbee thriller...@gmail.com wrote:
Thank you!
I'll give that a shot report back.
Ryan
On Fri, Oct 22, 2010 at 12:07 PM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi,
what group are you using for your destination (in dispatcher) ? if 0,
use another one :D...there is an issue there...
Regards,
Bogdan
thrillerbee wrote:
I could still use some help on understanding what I'm missing that is
preventing gws from transitioning back into the 'active' state from
'probing'. Currently, I have to babysit this OpenSIPS instance.
Again, to summarize, when dispatcher detects a failure, it puts the gw
into 'probing' state begins sending OPTIONS messages to the failed
gw. Even though the gateway begins replying with 200s, dispatcher
never returns it to an 'active' state. I have to restart OpenSIPS to
return it to an 'active' state.
Here are the relevant pieces of my config script:
# - dispatcher params -
modparam(dispatcher, flags, 2)
modparam(dispatcher, dst_avp, $avp(i:271))
modparam(dispatcher, attrs_avp, $avp(i:272))
modparam(dispatcher, grp_avp, $avp(i:273))
modparam(dispatcher, cnt_avp, $avp(i:274))
modparam(dispatcher, ds_ping_interval, 1)
modparam(dispatcher, ds_probing_threshhold, 32)
modparam(dispatcher, ds_probing_mode, 0)
modparam(dispatcher, options_reply_codes, 501, 403, 200)
failure_route[1]
{
if (t_was_cancelled()) {
exit;
}
if ((t_check_status(408)) (t_local_replied(last)))
{
xlog(L_ERR,Gateway Failure! $ci\n);
ds_mark_dst(p);
t_on_failure(1);
t_relay();
}
}
Again, any assistance would be greatly appreciated.
Thanks.
On Mon, Oct 18, 2010 at 7:31 AM, thrillerbee thriller...@gmail.com
mailto:thriller...@gmail.com wrote:
Anca,
I have configured the ds_probing_threshold parameter which allows
me to adjust when I gw goes from active to probing.
However, my issue is getting the gw back to active. For some
reason, it will never transition back - even with successful 200
OK responses to the OPTIONS messages that are triggered when a gw
goes to probing. The examples below show that I can't even
force it back to active from probing to active with MI commands -
I have to restart OpenSIPS.
Thanks.
On Mon, Oct 18, 2010 at 5:50 AM, Anca Vamanu a...@opensips.org
mailto:a...@opensips.org wrote:
Hi Thrillerbee,
You can try to adjust the time when a gateway state is
changed into probing by setting the ds_probing_threshhold ||
parameter
(
http://www.opensips.org/html/docs/modules/devel/dispatcher.html#id250525
).
Regards,
--
Anca Vamanu
www.voice-system.ro http://www.voice-system.ro
On 10/16/2010 08:01 AM, thrillerbee wrote:
I have been able to get the dispatcher module to detect a gw
failure and put it into a probing state route traffic
elsewhere. However, when the gw returns ( begins responding
to OPTIONS with 200s), dispatcher never puts it back in the
active state.
In fact, I cannot even manually put the server back in the
active state with mi functions. I can put it in an inactive
state, but it returns to probing if I try to set it to active:
ogw1:~# opensipsctl fifo ds_list
SET_NO:: 1
SET:: 0
URI:: sip:12.121.80.38 flag=P
URI:: sip:12.121.80.39 flag=A
URI:: sip:12.121.80.40 flag=A
ogw1:~# opensipsctl fifo ds_set_state i 0 sip:12.121.80.38
ogw1:~# opensipsctl fifo ds_list
SET_NO:: 1
SET:: 0
URI:: sip:12.121.80.38 flag=I
URI:: sip:12.121.80.39 flag=A
URI:: sip:12.121.80.40 flag=A
ogw1:~# opensipsctl fifo ds_set_state a 0 sip:12.121.80.38
ogw1:~# opensipsctl fifo ds_list
SET_NO:: 1
SET:: 0
URI:: sip:12.121.80.38 flag=P
URI:: sip:12.121.80.39 flag=A
URI:: sip:12.121.80.40 flag=A
Is there some setting that I am missing that allows gateways
to transition from probing to active?
Thanks.
___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin
[OpenSIPS-Users] 503 Server address has exceeded max calls in flight 75
Occasionally, I'm receiving a '503 Server address has exceed max calls in flight 75' from the b2bua opensips instance. What does this indicate? How is it prevented? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Dispatcher failover re-enabling with probing
I have been able to get the dispatcher module to detect a gw failure and put it into a probing state route traffic elsewhere. However, when the gw returns ( begins responding to OPTIONS with 200s), dispatcher never puts it back in the active state. In fact, I cannot even manually put the server back in the active state with mi functions. I can put it in an inactive state, but it returns to probing if I try to set it to active: ogw1:~# opensipsctl fifo ds_list SET_NO:: 1 SET:: 0 URI:: sip:12.121.80.38 flag=P URI:: sip:12.121.80.39 flag=A URI:: sip:12.121.80.40 flag=A ogw1:~# opensipsctl fifo ds_set_state i 0 sip:12.121.80.38 ogw1:~# opensipsctl fifo ds_list SET_NO:: 1 SET:: 0 URI:: sip:12.121.80.38 flag=I URI:: sip:12.121.80.39 flag=A URI:: sip:12.121.80.40 flag=A ogw1:~# opensipsctl fifo ds_set_state a 0 sip:12.121.80.38 ogw1:~# opensipsctl fifo ds_list SET_NO:: 1 SET:: 0 URI:: sip:12.121.80.38 flag=P URI:: sip:12.121.80.39 flag=A URI:: sip:12.121.80.40 flag=A Is there some setting that I am missing that allows gateways to transition from probing to active? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] failed to decode uri
I was forced to remove the OpenSIPS b2bua as it seems it was causing the origination gateway to choke on these 200 OKs. Dialogs are no longer hanging, but I still see errors on the origination gateway that are concerning: /usr/local/sbin/opensips[4399]: ERROR:core:parse_from_header: bad from header /usr/local/sbin/opensips[4399]: ERROR:rr:record_route: From parsing failed /usr/local/sbin/opensips[4402]: ERROR:core:parse_to: unexpected char [#000] in status 6: 2345678910sip:2345678...@6.12.24.48:5060 I can't find anything out of the ordinary in traces. What should I be looking for? Again, any help would be appreciated. Thanks. On Tue, Oct 12, 2010 at 9:15 PM, thrillerbee thriller...@gmail.com wrote: To add a little more detail, after doing some from uri normalization, this is eventually passed on to an OpenSIPS instance running b2bua for top hiding. I'm assuming this error indicates that the header param that is used to rebuild the original from uri is different than expected, but I don't see any discernible differences in a trace between the headers in the 200 OK (to the INVITE) and the provisional responses received right before it. The provisional responses are proxied; the 200 OK is not. Any help would be most appreciated. Thanks. On Tue, Oct 12, 2010 at 6:13 PM, thrillerbee thriller...@gmail.comwrote: I have dialogs getting stuck because my origination gateway (OpenSIPS proxy) fails to proxy 200 OKs to some INVITEs. In the logs, I see: /usr/local/sbin/opensips[30336]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30336]: ERROR:uac:restore_uri: failed to decode uri /usr/local/sbin/opensips[30337]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30337]: ERROR:uac:restore_uri: failed to decode uri I am doing some normalization of the from uri with uac_replace_from. What could cause this? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] failed to decode uri
I have dialogs getting stuck because my origination gateway (OpenSIPS proxy) fails to proxy 200 OKs to some INVITEs. In the logs, I see: /usr/local/sbin/opensips[30336]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30336]: ERROR:uac:restore_uri: failed to decode uri /usr/local/sbin/opensips[30337]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30337]: ERROR:uac:restore_uri: failed to decode uri I am doing some normalization of the from uri with uac_replace_from. What could cause this? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] failed to decode uri
To add a little more detail, after doing some from uri normalization, this is eventually passed on to an OpenSIPS instance running b2bua for top hiding. I'm assuming this error indicates that the header param that is used to rebuild the original from uri is different than expected, but I don't see any discernible differences in a trace between the headers in the 200 OK (to the INVITE) and the provisional responses received right before it. The provisional responses are proxied; the 200 OK is not. Any help would be most appreciated. Thanks. On Tue, Oct 12, 2010 at 6:13 PM, thrillerbee thriller...@gmail.com wrote: I have dialogs getting stuck because my origination gateway (OpenSIPS proxy) fails to proxy 200 OKs to some INVITEs. In the logs, I see: /usr/local/sbin/opensips[30336]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30336]: ERROR:uac:restore_uri: failed to decode uri /usr/local/sbin/opensips[30337]: ERROR:uac:decode_uri: invalid base64 stringAAUECAEIAwUHCQsip:12.24.48.96 /usr/local/sbin/opensips[30337]: ERROR:uac:restore_uri: failed to decode uri I am doing some normalization of the from uri with uac_replace_from. What could cause this? Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] stuck dialogs on proxy thru b2bua
Anca, After upgrade, the b2b_logic module will not initialize: /usr/local/sbin/opensips[12083]: ERROR:b2b_logic:mod_init: DB_URL parameter not set /usr/local/sbin/opensips[12083]: ERROR:core:init_mod: failed to initialize module b2b_logic /usr/local/sbin/opensips[12083]: ERROR:core:main: error while initializing modules Does it require access to a db now? Thanks. On Thu, Oct 7, 2010 at 3:35 AM, Anca Vamanu a...@opensips.org wrote: Hi, I have just made the commit, please update your code. Let me know if you still see this problem. Regards, -- Anca Vamanuwww.voice-system.ro On 10/07/2010 10:52 AM, Anca Vamanu wrote: Hi, I made some fixes regarding some similar cases - BYE not being transmitted on the other side, but only in trunk now. I will make the backport now and let you know when it is done. Regards, -- Anca Vamanuwww.voice-system.ro On 10/06/2010 07:45 PM, thrillerbee wrote: I've setup several OpenSIPS proxies (keeping track of dialogs,acc,etc.) behind a OpenSIPS B2BUA (to implement topology hiding - nothing else). I'm currently using version 1.6.3 on both the proxy b2bua. I updated the b2bua modules from svn yesterday. Certain dialogs hang because of how the B2BUA handles an inappropriate response to an INVITE in a never-established (canceled) dialog coupled with the proxy establishing a dialog after a CANCEL has been processed. After the initial call attempt is canceled, the upstream carrier responds with a 200 OK to the INVITE. The B2BUA sends that back to the OpenSIPS proxy. The OpenSIPS proxy creates a dialog even though the INVITE has been canceled. Soon afterwards, a BYE is received from upstream but the B2BUA does not send that back to the proxy. As a result, the dialog hangs (until the timeout is reached). I've tried to show the call flow below: ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] stuck dialogs on proxy thru b2bua
I've setup several OpenSIPS proxies (keeping track of dialogs,acc,etc.) behind a OpenSIPS B2BUA (to implement topology hiding - nothing else). I'm currently using version 1.6.3 on both the proxy b2bua. I updated the b2bua modules from svn yesterday. Certain dialogs hang because of how the B2BUA handles an inappropriate response to an INVITE in a never-established (canceled) dialog coupled with the proxy establishing a dialog after a CANCEL has been processed. After the initial call attempt is canceled, the upstream carrier responds with a 200 OK to the INVITE. The B2BUA sends that back to the OpenSIPS proxy. The OpenSIPS proxy creates a dialog even though the INVITE has been canceled. Soon afterwards, a BYE is received from upstream but the B2BUA does not send that back to the proxy. As a result, the dialog hangs (until the timeout is reached). I've tried to show the call flow below: proxy b2bua carrier - INV - 100 -- -- INV - 100 - - 183 - 183 -- --- CANCEL - 200(cancel)-- --- CANCEL - 200(cancel)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - 200(invite)-- - BYE - - 200(invite)-- - BYE - - 200(invite)-- I'm hoping I'm doing something stupid in my implementation that could cause this behavior. Thanks for any help that might resolve this issue. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
