24 Sep
2007
24 Sep
'07
6:31 p.m.
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from /usr/lib/perl5/auto/DBI/DBI.so
#9 0xb7c5c81b in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
#11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
#17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
#20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
/usr/lib/libperl.so.5.8
#21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
#22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
#23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
#24 0xb7c5af19 in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#25 0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78, branch=0,
msg_status=503, cancel_bitmap=0xbfb773a0) at t_reply.c:1035
#43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
#44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
#45 0x08084124 in receive_msg (
buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia: SIP/2.0/UDP
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo: <sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334, rcv_info=Variable "rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product, and
that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
The other and main reason is that for some unknown
reason the openSer
server crashes when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
then the openSer server dies.
This error is that kind of error that is specially difficult to find,
because there are too many different systems involded. The path from
openSer to the DB would be:
openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC ->
FreeTDS -> MS SQLServer
Yes, there are quite a bit modules involved.
Take a look into the core dump (set core_dump = yes) with gdb, this
should
give you further informations about the cause of the segmention fault.
To get
a better backtrace install the debug package (debian) or compile with
debugging enabled. If the error is located in openser, please post the
backtrace also on the list.
Cheers,
Henning
24 Sep
24 Sep
9:59 p.m.
New subject: [OpenSER-Users] perl + unixODBC
Hi Henning,
I found some documentation regarding perl and DBI - DBD::ODBC in multi
threaded environments:
- http://www.annocpan.org/~TIMB/DBI-1.59/DBI.pm - Threads and Thread
Safety section
- http://www.perlmonks.org/?node_id=631513
- http://www.perlmonks.org/index.pl?node_id=288022
These docs warn about the use of DBI (and other perl modules) with
Perl in multi threaded environments using iThread, which as I understood
is the Perl way of doing threads.
So first of all a question: does the Perl module uses iThreads?
I looked a little bit at the perl module code, and I saw that in the
perl.d (and perlfunc.d) file it includes the
/usr/lib/perl/5.8/CORE/thread.h header, which seems to define some perl
functions to use perl threads (iThread).
If the perl module really uses iThreads, then what I have to do is
clear, right? I have to take another path to communicate with my DB, as
the perl module isn't reliable when it uses DBI in multi threaded
environments.
Another path would be to make openser work in only one thread, but
that will affect the performance of my server.
Another question is: If the perl module really uses iThreads, then is
there another perl extension (like DBI) in which the same problem
occurs?
Thanks,
Murilo
-----Original Message-----
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On
Behalf Of Murilo Lacerda Yoshida
Sent: segunda-feira, 24 de setembro de 2007 12:31
To: users(a)openser.org
Subject: RE: [OpenSER-Users] perl + unixODBC
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from /usr/lib/perl5/auto/DBI/DBI.so
#9 0xb7c5c81b in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
#11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
#17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
#20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
/usr/lib/libperl.so.5.8
#21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
#22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
#23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
#24 0xb7c5af19 in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#25 0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78, branch=0,
msg_status=503, cancel_bitmap=0xbfb773a0) at t_reply.c:1035
#43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
#44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
#45 0x08084124 in receive_msg (
buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia: SIP/2.0/UDP
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo: <sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334, rcv_info=Variable "rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product, and
that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
The other and main reason is that for some unknown
reason the openSer
server crashes when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
then the openSer server dies.
This error is that kind of error that is specially difficult to find,
because there are too many different systems involded. The path from
openSer to the DB would be:
openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC ->
FreeTDS -> MS SQLServer
Yes, there are quite a bit modules involved.
Take a look into the core dump (set core_dump = yes) with gdb, this
should
give you further informations about the cause of the segmention fault.
To get
a better backtrace install the debug package (debian) or compile with
debugging enabled. If the error is located in openser, please post the
backtrace also on the list.
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
26 Sep
26 Sep
1:33 p.m.
New subject: [OpenSER-Users] perl + unixODBC
Hi,
sorry for not replying any earlier; I'm currently on my holidays and
(yet) have a very limited time for computer stuff :)
Your evaluation probably already pointed out the problems you
experience. Your backtrace shows that the segfault occurs during the
code in ODBC.so.
On Montag 24 September 2007, Murilo Lacerda Yoshida wrote:
So first of all a question: does the Perl module
uses iThreads?
The OpenSER perl module is linked against the system's perl library --
which will in most cases use the POSIX threading model (pthread) as its
underlying technology.
iThreads -- as far as I understood things -- refers to threading within
Perl itself, i.e. when you create threads from within Perl. In OpenSER,
the server itself forks.
The sections in the documentation that you found nonetheless probably
refer to the problems that you experience.
If the perl module really uses iThreads, then what I
have to do is
clear, right? I have to take another path to communicate with my DB,
as the perl module isn't reliable when it uses DBI in multi threaded
environments.
... or you need to find a way to communicate without using DBI -- which
may be quite a problem, anyway.
Another path would be to make openser work in only
one thread, but
that will affect the performance of my server.
Probably not an option, if you are stress testing your server?
Another question is: If the perl module really uses
iThreads, then
is there another perl extension (like DBI) in which the same problem
occurs?
Most Perl packages are "Perl only"; I would not expect to occur any
thread/multi-process related problems in these packages. Packages
with "XS" components (C libraries, resulting in .so files) are more
prone to raising problems similar to the one you are experiencing; code
they contain run in the same address space as the OpenSER server. Due
to this, they can crash the server and do (more or less) whatever they
want. Given the number of Perl packages (more than 4000 on cpan.org),
we cannont evaluate each of them :(
I'm not aware of any other "dangerous" packages, though.
I will add a "warnings" section in the perl module documentation as soon
as I have time.
Happy scripting,
Bastian
--
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10 www.collax.com
Geschäftsführer: William K. Hite / Boris Nalbach
AG München HRB 158898 . Ust.-IdNr: DE 814464942
\ A man with one watch knows what time it is.
\ A man with two watches is never quite sure.
9:27 p.m.
New subject: [OpenSER-Users] perl + unixODBC
Bastian,
I agree with all that you said... I found that documentation and thought that it might
apply to the error I was experiencing. In fact perl does not use iThread, openser forks
itself.
I guess that should exist a warning on the OpenSER Perl module documentation saying that
even if the Perl module handles the errors originated inside the Perl scripts, is possible
that the Perl module does not handle errors originated inside the Perl packages,
especially if the package is a .so lib (XS Perl package). In the worst case an error
originated inside this package can crash OpenSER.
Thanks for the help,
Murilo
-----Original Message-----
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf Of Bastian
Friedrich
Sent: quarta-feira, 26 de setembro de 2007 07:33
To: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
Hi,
sorry for not replying any earlier; I'm currently on my holidays and
(yet) have a very limited time for computer stuff :)
Your evaluation probably already pointed out the problems you
experience. Your backtrace shows that the segfault occurs during the
code in ODBC.so.
On Montag 24 September 2007, Murilo Lacerda Yoshida wrote:
So first of all a question: does the Perl module
uses iThreads?
The OpenSER perl module is linked against the system's perl library --
which will in most cases use the POSIX threading model (pthread) as its
underlying technology.
iThreads -- as far as I understood things -- refers to threading within
Perl itself, i.e. when you create threads from within Perl. In OpenSER,
the server itself forks.
The sections in the documentation that you found nonetheless probably
refer to the problems that you experience.
If the perl module really uses iThreads, then what I
have to do is
clear, right? I have to take another path to communicate with my DB,
as the perl module isn't reliable when it uses DBI in multi threaded
environments.
... or you need to find a way to communicate without using DBI -- which
may be quite a problem, anyway.
Another path would be to make openser work in only
one thread, but
that will affect the performance of my server.
Probably not an option, if you are stress testing your server?
Another question is: If the perl module really uses
iThreads, then
is there another perl extension (like DBI) in which the same problem
occurs?
Most Perl packages are "Perl only"; I would not expect to occur any
thread/multi-process related problems in these packages. Packages
with "XS" components (C libraries, resulting in .so files) are more
prone to raising problems similar to the one you are experiencing; code
they contain run in the same address space as the OpenSER server. Due
to this, they can crash the server and do (more or less) whatever they
want. Given the number of Perl packages (more than 4000 on cpan.org),
we cannont evaluate each of them :(
I'm not aware of any other "dangerous" packages, though.
I will add a "warnings" section in the perl module documentation as soon
as I have time.
Happy scripting,
Bastian
--
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10 www.collax.com
Geschäftsführer: William K. Hite / Boris Nalbach
AG München HRB 158898 . Ust.-IdNr: DE 814464942
\ A man with one watch knows what time it is.
\ A man with two watches is never quite sure.
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
24 Sep
24 Sep
10:23 p.m.
New subject: [OpenSER-Users] perl + unixODBC
If I'm understanding the dump you've included, it looks like you're
missing declarations for your variables "new_code" and
"rcv_info" in avpops.
They could be something like this in your OpenSER config file:
avp_aliases="new_code=i:34;rcv_info=i:36"
Then you can assign a value in Perl like so:
OpenSER::AVP::add(34, "$new_code");
Mik
Murilo Lacerda Yoshida wrote:
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from /usr/lib/perl5/auto/DBI/DBI.so
#9 0xb7c5c81b in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
#11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
#17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
#20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
/usr/lib/libperl.so.5.8
#21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
#22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
#23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
#24 0xb7c5af19 in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#25 0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78, branch=0,
msg_status=503, cancel_bitmap=0xbfb773a0) at t_reply.c:1035
#43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
#44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
#45 0x08084124 in receive_msg (
buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia: SIP/2.0/UDP
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo: <sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334, rcv_info=Variable "rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product,
and that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
The other and main reason is that for some
unknown reason the openSer
server crashes when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
then the openSer server dies.
This error is that kind of error that is specially difficult to find,
because there are too many different systems involded. The path from
openSer to the DB would be:
openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC ->
FreeTDS -> MS SQLServer
Yes, there are quite a bit modules involved.
Take a look into the core dump (set core_dump = yes) with gdb, this
should
give you further informations about the cause of the segmention fault.
To get
a better backtrace install the debug package (debian) or compile with
debugging enabled. If the error is located in openser, please post the
backtrace also on the list.
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:25 p.m.
New subject: [OpenSER-Users] perl + unixODBC
Mik,
Now I'm confused ... I saw this module AVPops and its functionality
and I decided not to use it ... but when I did this I checked if it was
essential for OpenSER, and I thought it was not.
I guess I was wrong then ... What value should the variables new_code
and rcv_info have?
What sounds strange to me is that the functions
t_should_relay_response and receive_msg (where these variables appear)
are not used by me on the script, they are used internally by OpenSER.
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 16:23
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
If I'm understanding the dump you've included, it looks like you're
missing declarations for your variables "new_code" and
"rcv_info" in avpops.
They could be something like this in your OpenSER config file:
avp_aliases="new_code=i:34;rcv_info=i:36"
Then you can assign a value in Perl like so:
OpenSER::AVP::add(34, "$new_code");
Mik
Murilo Lacerda Yoshida wrote:
find,
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from
/usr/lib/perl5/auto/DBI/DBI.so
#9 0xb7c5c81b in Perl_pp_entersub () from
/usr/lib/libperl.so.5.8
#10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
#11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
#17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
#20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
/usr/lib/libperl.so.5.8
#21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
#22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
#23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
#24 0xb7c5af19 in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#25 0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78,
branch=0,
msg_status=503, cancel_bitmap=0xbfb773a0) at
t_reply.c:1035
#43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
#44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
#45 0x08084124 in receive_msg (
buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia: SIP/2.0/UDP
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo:
<sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334, rcv_info=Variable
"rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
openSer
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product,
and that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
> The other and main reason is that for some unknown reason the server crashes
when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
> then the openSer server dies.
>
> This error is that kind of error that is specially difficult to > because there are too many different systems
involded. The path from
> openSer to the DB would be:
>
> openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC
->
FreeTDS ->
MS SQLServer
Yes, there are quite a bit modules involved.
Take a look into the core dump (set core_dump = yes) with gdb, this
should
give you further informations about the cause of the segmention fault.
To get
a better backtrace install the debug package (debian) or compile with
debugging enabled. If the error is located in openser, please post the backtrace also on the list.
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
25 Sep
25 Sep
12:12 a.m.
New subject: [OpenSER-Users] perl + unixODBC
Henning and I took a look at the backtrace this morning and briefly
chatted about it. I don't think that there are any AVP issues here.
new_code is a local program variable, not an AVP. It's being displayed
by gdb (which is a good thing for diagnosing problems).
I initially thought that the t_reply.c program and
t_should_relay_relay_response() subroutines weren't handling the "503"
failure properly. There is some interesting "if then" logic in the
subroutine.
After the comments about multi threaded code in perl and the fact that
the failure happens under heavy loads, it seems reasonable that is might
be where the problem is. I personally don't have much background with
multithreaded perl applications. This is a topic that looks as though
it needs more research.
Regards,
Norm
Murilo Lacerda Yoshida wrote:
Mik,
Now I'm confused ... I saw this module AVPops and its functionality
and I decided not to use it ... but when I did this I checked if it was
essential for OpenSER, and I thought it was not.
I guess I was wrong then ... What value should the variables new_code
and rcv_info have?
What sounds strange to me is that the functions
t_should_relay_response and receive_msg (where these variables appear)
are not used by me on the script, they are used internally by OpenSER.
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 16:23
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
If I'm understanding the dump you've included, it looks like you're
missing declarations for your variables "new_code" and
"rcv_info" in avpops.
They could be something like this in your OpenSER config file:
avp_aliases="new_code=i:34;rcv_info=i:36"
Then you can assign a value in Perl like so:
OpenSER::AVP::add(34, "$new_code");
Mik
Murilo Lacerda Yoshida wrote:
find,
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from
/usr/lib/perl5/auto/DBI/DBI.so
#9 0xb7c5c81b in Perl_pp_entersub () from
/usr/lib/libperl.so.5.8
#10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
#11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
#17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
#20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
/usr/lib/libperl.so.5.8
#21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
#22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
#23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
#24 0xb7c5af19 in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#25 0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78,
branch=0,
msg_status=503, cancel_bitmap=0xbfb773a0) at
t_reply.c:1035
#43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
#44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
#45 0x08084124 in receive_msg (
buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia: SIP/2.0/UDP
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo:
<sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334,
rcv_info=Variable "rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
openSer
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product,
and that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
> The other and main reason is that for some unknown reason the
> server
crashes when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
> then the openSer server dies.
>
> This error is that kind of error that is specially difficult to
> > because there are too many different systems
involded. The path from
> openSer to the DB would be:
>
> openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC
>
->
FreeTDS
-> MS SQLServer
Yes, there are quite a bit modules involved.
Take a look into the core dump (set core_dump = yes) with gdb, this
should
give you further informations about the cause of the segmention fault.
To get
a better backtrace install the debug package (debian) or compile with
debugging enabled. If the error is located in openser, please post the
backtrace also on the list.
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
12:28 a.m.
New subject: [OpenSER-Users] perl + unixODBC
Norman,
I think that too, specially because the system works at low load
environments. This makes me believe that the problem is related to the
load.
I will test Mik suggestion, that way the path form OpenSER to MSSQL will
be shorter:
openSer -> perl module -> perl -> perl DBI (DBD::Sybase) -> FreeTDS ->
MS SQLServer
Instead of
openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC ->
FreeTDS -> MS SQLServer
Thanks,
Murilo
-----Original Message-----
From: Norman Brandinger [mailto:norm@goes.com]
Sent: segunda-feira, 24 de setembro de 2007 18:13
To: Murilo Lacerda Yoshida
Cc: Mik Cheez; users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
Henning and I took a look at the backtrace this morning and briefly
chatted about it. I don't think that there are any AVP issues here.
new_code is a local program variable, not an AVP. It's being displayed
by gdb (which is a good thing for diagnosing problems).
I initially thought that the t_reply.c program and
t_should_relay_relay_response() subroutines weren't handling the "503"
failure properly. There is some interesting "if then" logic in the
subroutine.
After the comments about multi threaded code in perl and the fact that
the failure happens under heavy loads, it seems reasonable that is might
be where the problem is. I personally don't have much background with
multithreaded perl applications. This is a topic that looks as though
it needs more research.
Regards,
Norm
Murilo Lacerda Yoshida wrote:
SIP/2.0/UDP
find,
fault.
> backtrace also on the list.
>
> Cheers,
>
> Henning
>
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Mik,
Now I'm confused ... I saw this module AVPops and its functionality
and I decided not to use it ... but when I did this I checked if it
was
essential for OpenSER, and I thought it was not.
I guess I was wrong then ... What value should the variables
new_code
and rcv_info have?
What sounds strange to me is that the functions
t_should_relay_response and receive_msg (where these variables appear)
are not used by me on the script, they are used internally by OpenSER.
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 16:23
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
If I'm understanding the dump you've included, it looks like you're
missing declarations for your variables "new_code" and
"rcv_info" in avpops.
They could be something like this in your OpenSER config file:
avp_aliases="new_code=i:34;rcv_info=i:36"
Then you can assign a value in Perl like so:
OpenSER::AVP::add(34, "$new_code");
Mik
Murilo Lacerda Yoshida wrote:
/usr/lib/libperl.so.5.8
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from
/usr/lib/perl5/auto/DBI/DBI.so
> #9 0xb7c5c81b in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
> #10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
> #11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
> #12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
> #17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
> #20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
> /usr/lib/libperl.so.5.8
> #21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
> #22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
> #23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
> #24 0xb7c5af19 in Perl_runops_standard () from #25 0xb7bfcb6e
in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78,
branch=0,
> msg_status=503, cancel_bitmap=0xbfb773a0) at t_reply.c:1035
> #43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
> #44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
> #45 0x08084124 in receive_msg (
> buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia:
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo:
<sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334,
rcv_info=Variable "rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
openSer
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product,
and that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
> The other and main reason is that for some unknown reason the
> server
crashes when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
> then the openSer server dies.
>
> This error is that kind of error that is specially difficult to
> > because there are too many different systems
involded. The path from
> openSer to the DB would be:
>
> openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC
>
->
>> FreeTDS -> MS SQLServer
>>
> Yes, there are quite a bit modules involved.
>
> Take a look into the core dump (set core_dump = yes) with gdb, this
> should
> give you further informations about the cause of the segmention > To get
> a better backtrace install the debug package (debian) or compile with
> debugging enabled. If the error is located in
openser, please post
the
12:16 a.m.
New subject: [OpenSER-Users] perl + unixODBC
I see now, they *are* used internally...sorry to lead you on the wrong path.
I've actually had much better luck using the Sybase driver (DBD::Sybase)
with FreeTDS for MSSQL. I have several systems running with high loads
with no issues.
mIK
Can you send a
Murilo Lacerda Yoshida wrote:
Mik,
Now I'm confused ... I saw this module AVPops and its functionality
and I decided not to use it ... but when I did this I checked if it was
essential for OpenSER, and I thought it was not.
I guess I was wrong then ... What value should the variables new_code
and rcv_info have?
What sounds strange to me is that the functions
t_should_relay_response and receive_msg (where these variables appear)
are not used by me on the script, they are used internally by OpenSER.
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 16:23
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
If I'm understanding the dump you've included, it looks like you're
missing declarations for your variables "new_code" and
"rcv_info" in avpops.
They could be something like this in your OpenSER config file:
avp_aliases="new_code=i:34;rcv_info=i:36"
Then you can assign a value in Perl like so:
OpenSER::AVP::add(34, "$new_code");
Mik
Murilo Lacerda Yoshida wrote:
find,
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from
/usr/lib/perl5/auto/DBI/DBI.so
#9 0xb7c5c81b in Perl_pp_entersub () from
/usr/lib/libperl.so.5.8
#10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
#11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
#17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
#18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
#19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
#20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
/usr/lib/libperl.so.5.8
#21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
#22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
#23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
#24 0xb7c5af19 in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#25 0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78,
branch=0,
msg_status=503, cancel_bitmap=0xbfb773a0) at
t_reply.c:1035
#43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
#44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
#45 0x08084124 in receive_msg (
buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia: SIP/2.0/UDP
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo:
<sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334,
rcv_info=Variable "rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
openSer
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product,
and that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
> The other and main reason is that for some unknown reason the server
crashes when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
> then the openSer server dies.
>
> This error is that kind of error that is specially difficult to > because there are too many different systems
involded. The path from
> openSer to the DB would be:
>
> openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC
->
FreeTDS
-> MS SQLServer
Yes, there are quite a bit modules involved.
Take a look into the core dump (set core_dump = yes) with gdb, this
should
give you further informations about the cause of the segmention fault.
To get
a better backtrace install the debug package (debian) or compile with
debugging enabled. If the error is located in openser, please post the backtrace also on the list.
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
12:22 a.m.
New subject: [OpenSER-Users] perl + unixODBC
Yes, that probably is a good path ... I will test this.
Mik, when you say you have several systems running with high loads, you
have these systems running OpenSER and MSSQL? If so it's a good thing,
it means that it works...
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 18:17
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
I see now, they *are* used internally...sorry to lead you on the wrong
path.
I've actually had much better luck using the Sybase driver (DBD::Sybase)
with FreeTDS for MSSQL. I have several systems running with high loads
with no issues.
mIK
Can you send a
Murilo Lacerda Yoshida wrote:
SIP/2.0/UDP
find,
fault.
Mik,
Now I'm confused ... I saw this module AVPops and its functionality
and I decided not to use it ... but when I did this I checked if it
was
essential for OpenSER, and I thought it was not.
I guess I was wrong then ... What value should the variables
new_code
and rcv_info have?
What sounds strange to me is that the functions
t_should_relay_response and receive_msg (where these variables appear)
are not used by me on the script, they are used internally by OpenSER.
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 16:23
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
If I'm understanding the dump you've included, it looks like you're
missing declarations for your variables "new_code" and
"rcv_info" in avpops.
They could be something like this in your OpenSER config file:
avp_aliases="new_code=i:34;rcv_info=i:36"
Then you can assign a value in Perl like so:
OpenSER::AVP::add(34, "$new_code");
Mik
Murilo Lacerda Yoshida wrote:
/usr/lib/libperl.so.5.8
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from
/usr/lib/perl5/auto/DBI/DBI.so
> #9 0xb7c5c81b in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
> #10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
> #11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
> #12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
> #17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
> #20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
> /usr/lib/libperl.so.5.8
> #21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
> #22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
> #23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
> #24 0xb7c5af19 in Perl_runops_standard () from #25 0xb7bfcb6e
in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78,
branch=0,
> msg_status=503, cancel_bitmap=0xbfb773a0) at t_reply.c:1035
> #43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
> #44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
> #45 0x08084124 in receive_msg (
> buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia:
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo:
<sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334,
rcv_info=Variable "rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
openSer
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product,
and that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
> The other and main reason is that for some unknown reason the server
crashes when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
> then the openSer server dies.
>
> This error is that kind of error that is specially difficult to > because there are too many different systems
involded. The path from
> openSer to the DB would be:
>
> openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC
->
>> FreeTDS -> MS SQLServer
> Yes, there are quite a bit modules involved.
>
> Take a look into the core dump (set core_dump = yes) with gdb, this
> should
> give you further informations about the cause of the segmention > To get
> a better backtrace install the debug package (debian) or compile with
> debugging enabled. If the error is located in
openser, please post
the
backtrace also on the list.
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
12:40 a.m.
New subject: [OpenSER-Users] perl + unixODBC
I connect to several remote MSSQL servers this way, yeah ;)
Murilo Lacerda Yoshida wrote:
Yes, that probably is a good path ... I will test
this.
Mik, when you say you have several systems running with high loads, you
have these systems running OpenSER and MSSQL? If so it's a good thing,
it means that it works...
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 18:17
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
I see now, they *are* used internally...sorry to lead you on the wrong
path.
I've actually had much better luck using the Sybase driver (DBD::Sybase)
with FreeTDS for MSSQL. I have several systems running with high loads
with no issues.
mIK
Can you send a
Murilo Lacerda Yoshida wrote:
SIP/2.0/UDP
find,
fault.
Mik,
Now I'm confused ... I saw this module AVPops and its functionality
and I decided not to use it ... but when I did this I checked if it
was
essential for OpenSER, and I thought it was not.
I guess I was wrong then ... What value should the variables
new_code
and rcv_info have?
What sounds strange to me is that the functions
t_should_relay_response and receive_msg (where these variables appear)
are not used by me on the script, they are used internally by OpenSER.
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 16:23
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
If I'm understanding the dump you've included, it looks like you're
missing declarations for your variables "new_code" and
"rcv_info" in avpops.
They could be something like this in your OpenSER config file:
avp_aliases="new_code=i:34;rcv_info=i:36"
Then you can assign a value in Perl like so:
OpenSER::AVP::add(34, "$new_code");
Mik
Murilo Lacerda Yoshida wrote:
/usr/lib/libperl.so.5.8
Hi Henning,
This is the coredump for the crash described:
#0 0xb7dcd7c6 in raise () from /lib/libc.so.6
#1 0xb7dcf0e1 in abort () from /lib/libc.so.6
#2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
#3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
#4 0xb7e108e0 in free () from /lib/libc.so.6
#5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
#6 0xb5931f2e in odbc_st_destroy () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
/usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
#8 0xb5a30ac4 in XS_DBI_dispatch () from
/usr/lib/perl5/auto/DBI/DBI.so
> #9 0xb7c5c81b in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
> #10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
> #11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
> #12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
> #17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
> #18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
> #19 0xb7c69faf in Perl_sv_unref_flags () from /usr/lib/libperl.so.5.8
> #20 0xb7c68ce6 in Perl_sv_force_normal_flags () from
> /usr/lib/libperl.so.5.8
> #21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
> #22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
> #23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
> #24 0xb7c5af19 in Perl_runops_standard () from #25
0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78,
branch=0,
> msg_status=503, cancel_bitmap=0xbfb773a0) at t_reply.c:1035
> #43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
> #44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
> #45 0x08084124 in receive_msg (
> buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia:
192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
19---Type <return> to continue, or q <return> to quit---
2.168.3.186:5060\r\nTo:
<sip:1919%23007755115678@192.168.3.35>\r\nFrom:
<sip:115083400"..., len=334,
rcv_info=Variable "rcv_info" is not
available.
) at receive.c:195
#46 0x080b534a in udp_rcv_loop () at udp_server.c:465
#47 0x0807011b in main_loop () at main.c:834
#48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
Apparently the problem is somewhere in Perl?
Thanks,
Murilo
-----Original Message-----
From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
Sent: segunda-feira, 24 de setembro de 2007 05:23
To: users(a)openser.org
Cc: Murilo Lacerda Yoshida
Subject: Re: [OpenSER-Users] perl + unixODBC
On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
openSer
Hello all,
I'm new in the list, so first of all I would like to say hi to all
the
list and say that openSer is a fantastic product,
and that the
documentation available on the internet is also fantastic.
[..]
Hello Murilo,
nice to hear that. :-)
> The other and main reason is that for some unknown reason the server
crashes when using perl scripts that communicate with DB in
high
load contexts. For some reason the perl script
receives a sig_segv
(segmentation fault) and this signal is passed to all others threads
and
> then the openSer server dies.
>
> This error is that kind of error that is specially difficult to > because there are too many different systems
involded. The path from
> openSer to the DB would be:
>
> openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC
->
>> FreeTDS -> MS SQLServer
> Yes, there are quite a bit modules involved.
>
> Take a look into the core dump (set core_dump = yes) with gdb, this
> should
> give you further informations about the cause of the segmention > To get
> a better backtrace install the debug package (debian) or compile with
> debugging enabled. If the error is located in
openser, please post
the
backtrace
also on the list.
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
26 Sep
26 Sep
9:37 p.m.
New subject: [OpenSER-Users] perl + unixODBC
Hi Mik, Henning, Bastian, Norman,
I tried using DBD::Sybase and it worked! Probably it was an error in
the unixODBC lib or in the DBD::ODBC package. Anyway I did a first
stress test today and the server managed to complete 12000 calls in 2
hours. There is a lot of improvements to make in my script and on my DB,
but I think that the problem with OpenSER was solved (I hope!).
I will test the server exhaustively, and when it becomes stable I will
tell you what load it can handle.
For now thanks for the help!
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 18:41
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
I connect to several remote MSSQL servers this way, yeah ;)
Murilo Lacerda Yoshida wrote:
SIP/2.0/UDP
>> 192.168.3.35:5060;branch=z9hG4bK048c.9bab482.0\r\nVia: SIP/2.0/UDP
>> 19---Type <return> to continue, or q <return> to quit---
>> 2.168.3.186:5060\r\nTo:
> <sip:1919%23007755115678@192.168.3.35>\r\nFrom:
>> <sip:115083400"..., len=334, rcv_info=Variable "rcv_info" is
not
>> available.
>> ) at receive.c:195
>> #46 0x080b534a in udp_rcv_loop () at udp_server.c:465
>> #47 0x0807011b in main_loop () at main.c:834
>> #48 0x08071e65 in main (argc=3, argv=0xbfb77684) at main.c:1399
>>
>>
>> Apparently the problem is somewhere in Perl?
>>
>> Thanks,
>> Murilo
>>
>>
>>
>> -----Original Message-----
>> From: Henning Westerholt [mailto:henning.westerholt@1und1.de]
>> Sent: segunda-feira, 24 de setembro de 2007 05:23
>> To: users(a)openser.org
>> Cc: Murilo Lacerda Yoshida
>> Subject: Re: [OpenSER-Users] perl + unixODBC
>>
>> On Friday 21 September 2007, Murilo Lacerda Yoshida wrote:
>>> Hello all,
>>> I'm new in the list, so first of all I would like to say hi to all
>> the
>>> list and say that openSer is a fantastic product, and that the
>>> documentation available on the internet is also fantastic.
>>> [..]
>> Hello Murilo,
>>
>> nice to hear that. :-)
>>
>>> The other and main reason is that for some unknown reason the
> openSer
>>> server crashes when using perl scripts that communicate with DB in
>> high
>>> load contexts. For some reason the perl script receives a sig_segv
>>> (segmentation fault) and this signal is passed to all others threads
fault.
>> To get
>> a better backtrace install the debug package (debian) or compile with
Yes, that probably is a good path ... I will test
this.
Mik, when you say you have several systems running with high loads,
you
have these systems running OpenSER and MSSQL? If so
it's a good thing,
it means that it works...
Thanks,
Murilo
-----Original Message-----
From: Mik Cheez [mailto:michael_bulk@wildgate.com]
Sent: segunda-feira, 24 de setembro de 2007 18:17
To: Murilo Lacerda Yoshida
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] perl + unixODBC
I see now, they *are* used internally...sorry to lead you on the wrong
path.
I've actually had much better luck using the Sybase driver
(DBD::Sybase)
with FreeTDS for MSSQL. I have several systems running with high
loads
with no issues.
mIK
Can you send a
Murilo Lacerda Yoshida wrote:
appear)
Mik,
Now I'm confused ... I saw this module AVPops and its functionality
and I decided not to use it ... but when I did this I checked if it
was
essential for OpenSER, and I thought it was not.
I guess I was wrong then ... What value should the variables
new_code
> and rcv_info have?
>
> What sounds strange to me is that the functions
> t_should_relay_response and receive_msg (where these variables > are not used by me on the script, they are used
internally by
OpenSER.
>
> Thanks,
> Murilo
>
>
>
> -----Original Message-----
> From: Mik Cheez [mailto:michael_bulk@wildgate.com]
> Sent: segunda-feira, 24 de setembro de 2007 16:23
> To: Murilo Lacerda Yoshida
> Cc: users(a)openser.org
> Subject: Re: [OpenSER-Users] perl + unixODBC
>
> If I'm understanding the dump you've included, it looks like you're
> missing declarations for your variables "new_code" and
> "rcv_info" in avpops.
>
> They could be something like this in your OpenSER config file:
>
> avp_aliases="new_code=i:34;rcv_info=i:36"
>
> Then you can assign a value in Perl like so:
>
> OpenSER::AVP::add(34, "$new_code");
>
> Mik
>
>
> Murilo Lacerda Yoshida wrote:
>> Hi Henning,
>> This is the coredump for the crash described:
>>
>> #0 0xb7dcd7c6 in raise () from /lib/libc.so.6
>> #1 0xb7dcf0e1 in abort () from /lib/libc.so.6
>> #2 0xb7e04edb in __fsetlocking () from /lib/libc.so.6
>> #3 0xb7e0ce15 in malloc_set_state () from /lib/libc.so.6
>> #4 0xb7e108e0 in free () from /lib/libc.so.6
>> #5 0xb7c4ce71 in Perl_safesysfree () from /usr/lib/libperl.so.5.8
>> #6 0xb5931f2e in odbc_st_destroy () from
>> /usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
>> #7 0xb59271fa in XS_DBD__ODBC__st_DESTROY () from
>> /usr/local/lib/perl/5.8.8/auto/DBD/ODBC/ODBC.so
>> #8 0xb5a30ac4 in XS_DBI_dispatch () from
> /usr/lib/perl5/auto/DBI/DBI.so
>> #9 0xb7c5c81b in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
>> #10 0xb7bfcb91 in Perl_magicname () from /usr/lib/libperl.so.5.8
>> #11 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
>> #12 0xb7c69627 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
>> #13 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
>> #14 0xb7c69951 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
>> #15 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
>> #16 0xb7c4e5bc in Perl_mg_free () from /usr/lib/libperl.so.5.8
>> #17 0xb7c69834 in Perl_sv_clear () from /usr/lib/libperl.so.5.8
>> #18 0xb7c69e93 in Perl_sv_free () from /usr/lib/libperl.so.5.8
>> #19 0xb7c69faf in Perl_sv_unref_flags () from
/usr/lib/libperl.so.5.8
> #20
0xb7c68ce6 in Perl_sv_force_normal_flags () from
> /usr/lib/libperl.so.5.8
> #21 0xb7c8b336 in Perl_leave_scope () from /usr/lib/libperl.so.5.8
> #22 0xb7c8b413 in Perl_pop_scope () from /usr/lib/libperl.so.5.8
> #23 0xb7c951eb in Perl_pp_return () from /usr/lib/libperl.so.5.8
> #24 0xb7c5af19 in Perl_runops_standard () from
/usr/lib/libperl.so.5.8
#25
0xb7bfcb6e in Perl_magicname () from /usr/lib/libperl.so.5.8
#26 0xb7bfd844 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#27 0xb7bfe445 in Perl_call_pv () from /usr/lib/libperl.so.5.8
#28 0xb7d0a2df in perl_exec2 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
mystr=0x0) at perlfunc.c:150
#29 0xb7d0a56c in perl_exec1 (_msg=0xb7d8b020, fnc=0x817e490 "CSP",
foobar=0x0) at perlfunc.c:90
#30 0x08053116 in do_action (a=0x817e518, msg=0xb7d8b020) at
action.c:883
#31 0x080553ea in run_action_list (a=0x817e518, msg=0xb7d8b020) at
action.c:131
#32 0x08091582 in eval_expr (e=0x817e570, msg=0xb7d8b020,
val=0xbfb76b88) at route.c:1058
#33 0x08054d60 in do_assign (msg=0xb7d8b020, a=0x817e598) at
action.c:198
#34 0x080527cb in do_action (a=0x817e598, msg=0xb7d8b020) at
action.c:986
#35 0x080553ea in run_action_list (a=0x817e028, msg=0xb7d8b020) at
action.c:131
#36 0x080543dd in do_action (a=0x81819a0, msg=0xb7d8b020) at
action.c:801
#37 0x080553ea in run_action_list (a=0x817d250, msg=0xb7d8b020) at
action.c:131
#38 0x08053a3b in do_action (a=0x81830e8, msg=0xb7d8b020) at
action.c:111
#39 0x080553ea in run_action_list (a=0x8182e48, msg=0xb7d8b020) at
action.c:131
#40 0x08055669 in run_top_route (a=0x8182e48, msg=0xb7d8b020) at
action.c:111
#41 0xb7d79bb6 in t_should_relay_response (Trans=0xb5c87e18,
new_code=Variable "new_code" is not available.
) at t_reply.c:601
#42 0xb7d79e4d in relay_reply (t=0xb5c87e18, p_msg=0x8188a78,
branch=0,
> msg_status=503, cancel_bitmap=0xbfb773a0) at t_reply.c:1035
> #43 0xb7d7c30b in reply_received (p_msg=0x8188a78) at t_reply.c:1383
> #44 0x080614bb in forward_reply (msg=0x8188a78) at forward.c:489
> #45 0x08084124 in receive_msg (
> buf=0x8140860 "SIP/2.0 503 Service Unavailable\r\nVia: >> and
>>> then the openSer server dies.
>>>
>>> This error is that kind of error that is specially difficult to
> find,
>>> because there are too many different systems involded. The path
from
> openSer to the DB would be:
>
> openSer -> perl module -> perl -> perl DBI (DBD::ODBC) -> unixODBC
->
>> FreeTDS -> MS SQLServer
> Yes, there are quite a bit modules involved.
>
> Take a look into the core dump (set core_dump = yes) with gdb, this
> should
> give you further informations about the cause of the segmention > debugging enabled. If the error is located in
openser, please post
the
backtrace
also on the list.
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6270
days inactive
6272
days old
11 comments
4 participants
participants (4)
-
Bastian Friedrich -
Mik Cheez -
Murilo Lacerda Yoshida -
Norman Brandinger