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:[EMAIL PROTECTED] Sent: segunda-feira, 24 de setembro de 2007 18:17 To: Murilo Lacerda Yoshida Cc: users@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: > 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:[EMAIL PROTECTED] > Sent: segunda-feira, 24 de setembro de 2007 16:23 > To: Murilo Lacerda Yoshida > Cc: users@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: 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:[EMAIL PROTECTED]>\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:[EMAIL PROTECTED] >> Sent: segunda-feira, 24 de setembro de 2007 05:23 >> To: users@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@openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users