[OpenSIPS-Users] cache_* and mutexes
Hello. Do cache_fetch and cache_store functions have any locking mechanism to prevent race condition? $shv variables? WBR, Anton Zagorskiy VoIP Developer, Oyster Telecom Phone.: +7 812 601-0666 Fax: +7 812 601-0593 a.zagors...@oyster-telecom.ru www.oyster-telecom.ru ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] MySQL LAST_INSERT_ID() safe?
Hi Bogdan,
Thanks very much for clarification.
Best regards,
Chris
On 30 November 2010 20:21, Bogdan-Andrei Iancu bog...@voice-system.ro wrote:
Hi Chris,
It is safe, as opensips has a mysql connection for each process and a script
route is continuously executed by a single process. So your queries will go
via same connection with no risk to have something else between.
Regards,
Bogdan
Chris Maciejewski wrote:
Hi,
I am trying to figure out if is it safe to use in OpenSIPs config file:
avp_db_query(INSERT INTO some_table VALUES ('data1'));
avp_db_query(SELECT LAST_INSERT_ID(),$avp(last_id););
// do stuff with $avp(last_id);
How does OpenSIPs connects to MySQL sever? Does it use some smart
connection pooling maybe, which could result in unexpected behaviour?
Regards,
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] cache_* and mutexes
Hi Anton, yes, both systems do have a sync mechanism. Regards, Bogdan Anton Zagorskiy wrote: Hello. Do cache_fetch and cache_store functions have any locking mechanism to prevent race condition? $shv variables? WBR, Anton Zagorskiy VoIP Developer, Oyster Telecom Phone.: +7 812 601-0666 Fax: +7 812 601-0593 a.zagors...@oyster-telecom.ru www.oyster-telecom.ru ___ 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
Re: [OpenSIPS-Users] opensips 100% cpu
Hi,
it looks like the lock is kept by another process doing some stuff
related to that transaction...maybe processing a different reply...Did
you add some new stuff in onreply route ?
could you run with full logs (debug=6) and send me those logs (for the
entire call) ?
Regards,
Bogdan
Ангелов К.Н. wrote:
Hello,
my opensips process goes to 100% cpu after first call with default
script and auth_aaa module enabled.
No such problem at all when auth_aaa disabled. OS FreeBSD 8.1/amd64
#loadmodule auth_aaa.so
#modparam(auth_aaa, aaa_url,
radius:/usr/local/etc/radiusclient-ng/radiusclient.conf)
#modparam(auth_aaa, service_type, 15)
It hangs at modules/tm/t_reply.c on LOCK_REPLIES( t );
*
+if (!onreply_avp_mode) LM_DBG(!onreply_avp_mode!\n);
+if (!has_reply_route) LM_DBG(!has_reply_route!\n);
if (!onreply_avp_mode || !has_reply_route) {
+ LM_DBG(Before lock\n);
/* lock the reply*/
LOCK_REPLIES( t );
+ LM_DBG(After lock\n);
}
Here logs, without loadmodule auth_aaa.so and modparam auth_aaa
Nov 26 15:33:14 noc-pbx /usr/local/sbin/opensips[70850]:
DBG:tm:reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=0)
Nov 26 15:33:14 noc-pbx /usr/local/sbin/opensips[70850]:
DBG:tm:reply_received: !onreply_avp_mode!
Nov 26 15:33:14 noc-pbx /usr/local/sbin/opensips[70850]:
DBG:tm:reply_received: !has_reply_route!
Nov 26 15:33:14 noc-pbx /usr/local/sbin/opensips[70850]:
DBG:tm:reply_received: Before lock
Nov 26 15:33:14 noc-pbx /usr/local/sbin/opensips[70850]:
DBG:tm:reply_received: After lock
Nov 26 15:33:14 noc-pbx /usr/local/sbin/opensips[70850]:
DBG:tm:t_should_relay_response: T_code=0, new_code=200
Nov 26 15:33:14 noc-pbx /usr/local/sbin/opensips[70850]:
DBG:tm:relay_reply: branch=0, save=0, relay=0
with them
Nov 26 15:35:33 noc-pbx /usr/local/sbin/opensips[70900]:
DBG:tm:reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=0)
Nov 26 15:35:33 noc-pbx /usr/local/sbin/opensips[70900]:
DBG:tm:reply_received: !onreply_avp_mode!
Nov 26 15:35:33 noc-pbx /usr/local/sbin/opensips[70900]:
DBG:tm:reply_received: !has_reply_route!
Nov 26 15:35:33 noc-pbx /usr/local/sbin/opensips[70900]:
DBG:tm:reply_received: Before lock
..100%CPU.
gdb
Loaded symbols for /usr/local/lib/libradiusclient-ng.so.2
Reading symbols from /usr/local/lib/opensips/modules/auth_aaa.so...(no
debugging symbols found)...done.
Loaded symbols for /usr/local/lib/opensips/modules/auth_aaa.so
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols
found)...done.
Loaded symbols for /libexec/ld-elf.so.1
[Switching to Thread 800c041c0 (LWP 100216)]
0x00080089e74c in sched_yield () from /lib/libc.so.7
(gdb) bt
#0 0x00080089e74c in sched_yield () from /lib/libc.so.7
#1 0x00080073e10f in pthread_mutex_getyieldloops_np ()
from /lib/libthr.so.3
#2 0x0008014f98a2 in reply_received ()
from /usr/local/lib/opensips/modules/tm.so
#3 0x0041c5fe in forward_reply ()
#4 0x00444078 in receive_msg ()
#5 0x004746d4 in udp_rcv_loop ()
#6 0x00422b5a in main ()
*
Any tips ?
___
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
Re: [OpenSIPS-Users] Solaris Opensips
Hi Nicholas, In Makefile file, there is block at line 91: # fix sparc - sparc64 ifeq ($(ARCH),sparc) ifeq ($(shell uname -m),sun4u) ARCH := sparc64 endif ifeq ($(shell uname -m),sun4v) ARCH := sparc64 endif endif Take it out and see if compiles. Regards, Bogdan Nicholas Papadakos wrote: Hello, I have noticed there are no re-compiled packages on the opensips website for recent versions of opensips. I am trying to compile by source opensips-1.6.3-notls and I get the following error . I am using gmake gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) uname -a SunOS hiro 5.10 Generic_141444-09 sun4u sparc SUNW,UltraAX-i2 I noted there was asimular post last year but no reply:( AVE_DEVPOLL -DHAVE_SELECT -c blacklists.c -o blacklists.o /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 223: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 243: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 267: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 298: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 318: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 340: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 371: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 391: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 414: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 455: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 475: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 497: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 594: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 612: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 635: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 667: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 685: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 721: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 753: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 771: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 796: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 868: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 888: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 910: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 1426: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 1446: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 1469: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 1528: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 1548: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 1571: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 2047: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 2067: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as: /var/tmp//cch4baDb.s, line 2092: error: cannot use v8plus instructions in a non-v8plus target binary /usr/ccs/bin/as:
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] Debugging variables in failure_route
Thanks so much Bogdan! I do appreciate all your hard work! Bill W On 11/30/10 3:12 PM, Bogdan-Andrei Iancu wrote: Hi Bill, you can use t_local_replied(last) in failure route to see if the 408 was locally generated or was received. See: http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id294010 Regards, bogdan Bill W. wrote: Hello everyone, I'm trying to debug an issue where something is intermittently sending a 408 Request timed out which is being caught by t_check_status(408) in a failure_route. And actually, I think opensips might be generating it internally because the INVITE message id is very different than the message id of the 408. ($mi=385 vs $mi=1) Regardless, all the variables I've tried to log inside the failure_route pertain to the initial INVITE, so they are of no help. I even tried $(replyrs) and $(replyrr) but those both show null. So the question is: are there any variables I can log within the failure_route to determine the source of that SIP 408? Thanks! Bill W. ___ 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] Load balancer probing from incorrect interface
Hey Bogdan, Thanks so much for your help. For the benefit of the group, I eventually came up with a work-around for this. I use the following in opensips.cfg listen=udp:probe-internal:5090 listen=udp:probe-external:5090 Then in the hosts file on machine A I put: 10.0.10.1 probe-internal 66.180.205.11 probe-external And on machine B I put: 10.0.10.2 probe-internal 66.180.205.12 probe-external So when opensips fails over from A to B, it picks up the new probing-IP from the hosts file. Then the probes from the default IP as selected by the kernel routing table work correctly, as they are coming from a port other than 5060. Hope this helps, Bill On 11/24/10 6:10 AM, Bogdan-Andrei Iancu wrote: Bill W. wrote: Hello Bogdan, Okay I've been researching this more. I am not a programmer, but it looks like get_out_socket and find_si in forward.c and socket_info.c are just comparing ip addresses, and when opensips is trying to probe an interface on the same machine, but is not bound to that IP, then source IP address selection fails. The challenge is that my instance of opensips is an HA service between two machines, so I cannot simply specify IPs to listen on in opensips.cfg because the source IPs I need to probe from will change depending on which machine opensips is running on. That is not possible - you cannot change at runtime the interfaces opensips works with - you cannot make it to listen on a newly added interface, you cannot make it stop using an already configured interface. Each time you change the interfaces on the server, if you need to restart opensips. It looks like the solution to make this work with the existing get_out_socket code is to be able to specify interface aliases in the listen= directive. If I could do something like this: listen=udp:eth0:5090# for probing eth0 IP alias listen=udp:eth0.0:5090# for probing eth0:0 IP alias listen=udp:eth1.1:5090# for probing eth1:1 IP alias Then opensips could pick the appropriate IP from the interface/alias on the machine where it is running. If that's too complex, then the brute-force method would be to allow this: listen=udp:*:5090# for probing to be honest, never tried something like that - let me know if it works for you Regards, Bogdan I can't simply use the port= directive because I've got other services running on 5060. Thoughts? Thanks! Bill On 11/12/10 8:27 PM, Bill W wrote: Hi Bogdan, Thanks so much for explaining how interface selection works. Unfortunately the other interfaces all have daemons listening on port 5060 and are in production and I can't simply reallocate IPs. So for the error messages below, is the problem that opensips is trying to send out a packet on the automatically selected IP but since port 5060 is occupied on that address, the socket is failing? If so, is it possible to specify a different source port so the packet will go out? Thanks, Bill ___ 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] db_mysql core dump
Sure. I am game. I could also send you the full config I am using, but it is pretty much word for word when it comes to the presence install shown on (word for word when it comes to the subscribe, publish, notify handling) http://openxcap.org/wiki/Configuration Just a thought. Send the patch over whenever. On Tue, Nov 30, 2010 at 1:20 PM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Duane, yes, that is...but fortunately does not provide the information I was hoping for Is it ok if I will send you a patch that will enable kind of hunting for this bug ? Regards, Bogdan Duane Larson wrote: I believe this is what you wanted (gdb) frame 2 #2 0x7f176faf8f22 in db_mysql_delete (_h=0x812f20, _k=0x7fff61728980, _o=0x7fff61728960, _v=0x7fff61728900, _n=2) at dbase.c:893 893 ret = db_mysql_do_prepared_query(_h, query_holder, _v, _n, NULL, 0); (gdb) print _h $2 = (const db_con_t *) 0x812f20 (gdb) print _h-curr_ps $3 = (db_ps_t *) 0x7f176c46d2b0 (gdb) print (struct prep_stmt*)(*(_h)-curr_ps) $4 = (struct prep_stmt *) 0x813650 (gdb) print ((struct prep_stmt*)(*(_h)-curr_ps))-stmts $5 = (struct my_stmt_ctx *) 0x814d10 (gdb) print ((struct prep_stmt*)(*(_h)-curr_ps))-stmts-table.s $6 = 0x814d48 watchersdelete from watchers where inserted_time? AND status=?.26705.61.7 (gdb) print ((struct prep_stmt*)(*(_h)-curr_ps))-stmts-query.s $7 = 0x814d50 delete from watchers where inserted_time? AND status=?.26705.61.7 On Wed, Nov 24, 2010 at 5:29 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi Duane, in frame 2 print the followings: _h _h-curr_ps (struct prep_stmt*)(*(_h)-curr_ps) ((struct prep_stmt*)(*(_h)-curr_ps))-stmts ((struct prep_stmt*)(*(_h)-curr_ps))-stmts-table.s ((struct prep_stmt*)(*(_h)-curr_ps))-stmts-query.s Thanks and regards, Bogdan duane.lar...@gmail.com mailto:duane.lar...@gmail.com wrote: I searched the mailing list and couldn't find anything related to this. For the last couple of nights OpenSIPS has died on me. Each time in Syslog I see Nov 13 02:54:25 Proxy01 kernel: [1750051.944109] opensips[6645]: segfault at 0 ip 7f7fd431bafd sp 7fff67048fc0 error 6 in db_mysql.so[7f7fd4311000+d 000] Nov 13 02:54:25 Proxy01 ./opensips[6654]: CRITICAL:core:receive_fd: EOF on 24 Nov 13 02:54:25 Proxy01 ./opensips[6631]: INFO:core:handle_sigs: child process 6645 exited by a signal 11 Nov 13 02:54:25 Proxy01 ./opensips[6631]: INFO:core:handle_sigs: core was generated Nov 13 02:54:25 Proxy01 ./opensips[6631]: INFO:core:handle_sigs: terminating due to SIGCHLD The backtrace has the following Core was generated by `./opensips -f /usr/local/etc/opensips/opensips.cfg'. Program terminated with signal 11, Segmentation fault. #0 0x7f7fd431bafd in db_mysql_val2bind (v=0x7fff67049120, binds=0x7ffd68, i=112) at val.c:274 274 *(binds[i].is_null) = 0; (gdb) backtrace #0 0x7f7fd431bafd in db_mysql_val2bind (v=0x7fff67049120, binds=0x7ffd68, i=112) at val.c:274 #1 0x7f7fd431607a in db_mysql_do_prepared_query (conn=0x7ff5f8, query=0x7f7fd452e6d0, v=0x7fff67049100, n=2, uv=0x0, un=0) at dbase.c:443 #2 0x7f7fd4318305 in db_mysql_delete (_h=0x7ff5f8, _k=0x7fff67049180, _o=0x7fff67049160, _v=0x7fff67049100, _n=2) at dbase.c:893 #3 0x7f7fd0a96b10 in msg_watchers_clean (ticks=value optimized out, param=value optimized out) at subscribe.c:484 #4 0x0049e3da in timer_ticker () at timer.c:325 #5 run_timer_process () at timer.c:395 #6 start_timer_processes () at timer.c:475 #7 0x0042be57 in main_loop (argc=value optimized out, argv=0x7fff67049378) at main.c:867 #8 main (argc=value optimized out, argv=0x7fff67049378) at main.c:1388 If need be I could also look in the MySQL logs and see what the last execution was. Any ideas? ___ 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 -- -- *--*--*--*--*--* Duane *--*--*--*--*--* --
[OpenSIPS-Users] Installation procedure for OPEN-SIP on UBUNTU
Dear All, Anybody please help me for installing Open-SIP on Ubuntu OS. Any document/procedure please share -- thanking you in advance, Pradeep ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] lawful interception with opensips
Hi, Is there any awailable howto/solution for doing lawful interception with using opensips? Since it's 98% about the media, I guess Asterisk or something else may involved in the setup, with some media forking. I have read a tons of topics after a Google search, but all answers are just theoretical, not to menion that I'm not looking for call recording and then listen the recorded call, but the ability to listen the live call (which should be done undetecable by the call parties). Kind regards, Dimitri ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] registration to other SIP proxies?
Hi all, Is it possible for OpenSIPS to register to other SIP proxies? Or if not has anyone found a way to do this indirectly? -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
