Is anyone out there using app_dbodbc
(http://www.bkw.org/~brian/app_dbodbc.c)? Any problems with it?
I was able to get it all working, but it causes * to segfault every now
and then. It does not appear to be related to any specific function
(ODBCget,ODBCput,ODBCdel,ODBCdelltree). It is 100% repeatable. If I
noload the module, everything works fine, but when its running, after
calls to any of the applications, * will randomly segfault. The data is
going in and out of the database with no problems. I compared the code
to app_db.c, and its very similar. I cannot see anything that would be
causing it.
I am using latest CVS as of an hour ago. ODBC connection is to a mysql
database.
For what its worth, I ported app_dbodbc.c to a new app_dbmysql.c and
created MySQLget, MySQLput, MySQLdel and MySQLdeltree, and experience
the exact same problem. If anyone wants the app_dbmysql.c, let me know.
I am using this to implement the call forward examples found at
voip-info.org. extensions.conf snippit:
[macro-sipexten]
exten => s,1,SetVar(OrigNum=${ARG1})
exten => s,2,ODBCput(CallReturn/${ARG1}=${CALLERIDNUM})
exten => s,3,ODBCget(temp=CFIM/${ARG1}) ; Get CFIM key, if not existing,
goto 104
exten => s,4,Goto(default|${temp}|1) ; Unconditional forward
exten => s,5,Dial(SIP/${ARG1},20) ; 20sec timeout
exten => s,6,ODBCget(temp2=CFBS/${ARG1}) ; Get CFBS key, if not
existing, goto 107
exten => s,7,Goto(default|${temp2}|1) ; Forward on busy or unavailable
; No CFIM key
exten => s,104,Goto(s,5)
; No CFBS key - voicemail
exten => s,107,Voicemail(u${ARG1}) ; If no voicemail box for this user,
goto 208
exten => s,108,Hangup
exten => s,208,Playback(ss-noservice) ; Play no service message
exten => s,209,SayDigits(${ARG1}) ; and say back the number they
called
exten => s,210,Hangup
At startup:
[app_dbodbc.so] => (Database access functions for Asterisk extension
logic)
== Parsing '/etc/asterisk/odbc.conf': Found
> app_dbodbc: dsn is MySQL-asterisk
> app_dbodbc: username is asterisk
> app_dbodbc: password is [secret]
> app_dbodbc: Connected to MySQL-asterisk
== Registered application 'ODBCget'
== Registered application 'ODBCput'
== Registered application 'ODBCdel'
== Registered application 'ODBCdeltree'
Sample crash:
-- Starting simple switch on 'Zap/23-1'
-- Executing Macro("Zap/23-1", "sipexten|9161111111") in
new stack
-- Executing SetVar("Zap/23-1", "OrigNum=9161111111") in
new stack
-- Executing ODBCput("Zap/23-1",
"CallReturn/9161111111=9162222222")
in new stack
-- odbcput: family=CallReturn, key=9161111111, value=9162222222
> app_dbodbc: Query Successful!
> app_dbodbc: Query Successful!
-- Executing ODBCget("Zap/23-1", "temp=CFIM/9161111111")
in new
stack
-- odbcget: varname=temp, family=CFIM, key=9161111111
> app_dbodbc: Query Successful!
-- odbcget: Value not found in database.
-- Executing Goto("Zap/23-1", "s|5") in new stack
-- Goto (macro-sipexten,s,5)
-- Executing Dial("Zap/23-1", "SIP/9161111111|20") in
new stack
Segmentation fault
smf-ast1:~# Ouch ... error while writing audio data: : Broken pipe
As I said, if I change these back to DBxxx, and noload app_dbodbc.so, no
problems at all. 100% repeatable. When I look in the astdb mysql table,
all the data that was ODBCput is there.
Thoughts?
Ya that one is not the latest one... I'll dig up the one that works! If you can provide me a bt I can fix it! :) bkw> -----Original Message----- > From: asterisk-users-admin@lists.digium.com [mailto:asterisk-users- > admin@lists.digium.com] On Behalf Of Mike Machado > Sent: Friday, April 30, 2004 2:05 PM > To: asterisk-users@lists.digium.com > Subject: [Asterisk-Users] app_dbodbc segfault > > > Is anyone out there using app_dbodbc > (http://www.bkw.org/~brian/app_dbodbc.c)? Any problems with it? > > I was able to get it all working, but it causes * to segfault every now > and then. It does not appear to be related to any specific function > (ODBCget,ODBCput,ODBCdel,ODBCdelltree). It is 100% repeatable. If I > noload the module, everything works fine, but when its running, after > calls to any of the applications, * will randomly segfault. The data is > going in and out of the database with no problems. I compared the code > to app_db.c, and its very similar. I cannot see anything that would be > causing it. > > I am using latest CVS as of an hour ago. ODBC connection is to a mysql > database. > > For what its worth, I ported app_dbodbc.c to a new app_dbmysql.c and > created MySQLget, MySQLput, MySQLdel and MySQLdeltree, and experience > the exact same problem. If anyone wants the app_dbmysql.c, let me know. > > > I am using this to implement the call forward examples found at > voip-info.org. extensions.conf snippit: > > > [macro-sipexten] > > exten => s,1,SetVar(OrigNum=${ARG1}) > > exten => s,2,ODBCput(CallReturn/${ARG1}=${CALLERIDNUM}) > exten => s,3,ODBCget(temp=CFIM/${ARG1}) ; Get CFIM key, if not existing, > goto 104 > exten => s,4,Goto(default|${temp}|1) ; Unconditional forward > exten => s,5,Dial(SIP/${ARG1},20) ; 20sec timeout > exten => s,6,ODBCget(temp2=CFBS/${ARG1}) ; Get CFBS key, if not > existing, goto 107 > exten => s,7,Goto(default|${temp2}|1) ; Forward on busy or unavailable > > ; No CFIM key > exten => s,104,Goto(s,5) > > ; No CFBS key - voicemail > exten => s,107,Voicemail(u${ARG1}) ; If no voicemail box for this user, > goto 208 > exten => s,108,Hangup > > exten => s,208,Playback(ss-noservice) ; Play no service message > exten => s,209,SayDigits(${ARG1}) ; and say back the number they > called > exten => s,210,Hangup > > > > > At startup: > > [app_dbodbc.so] => (Database access functions for Asterisk extension > logic) > == Parsing '/etc/asterisk/odbc.conf': Found > > app_dbodbc: dsn is MySQL-asterisk > > app_dbodbc: username is asterisk > > app_dbodbc: password is [secret] > > app_dbodbc: Connected to MySQL-asterisk > == Registered application 'ODBCget' > == Registered application 'ODBCput' > == Registered application 'ODBCdel' > == Registered application 'ODBCdeltree' > > > > Sample crash: > > > -- Starting simple switch on 'Zap/23-1' > -- Executing Macro("Zap/23-1", "sipexten|9161111111") in new stack > -- Executing SetVar("Zap/23-1", "OrigNum=9161111111") in new stack > -- Executing ODBCput("Zap/23-1", "CallReturn/9161111111=9162222222") > in new stack > -- odbcput: family=CallReturn, key=9161111111, value=9162222222 > > app_dbodbc: Query Successful! > > app_dbodbc: Query Successful! > -- Executing ODBCget("Zap/23-1", "temp=CFIM/9161111111") in new > stack > -- odbcget: varname=temp, family=CFIM, key=9161111111 > > app_dbodbc: Query Successful! > -- odbcget: Value not found in database. > -- Executing Goto("Zap/23-1", "s|5") in new stack > -- Goto (macro-sipexten,s,5) > -- Executing Dial("Zap/23-1", "SIP/9161111111|20") in new stack > Segmentation fault > smf-ast1:~# Ouch ... error while writing audio data: : Broken pipe > > > > As I said, if I change these back to DBxxx, and noload app_dbodbc.so, no > problems at all. 100% repeatable. When I look in the astdb mysql table, > all the data that was ODBCput is there. > > Thoughts? > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
Hi!> bt = Back trace? > > My gdb experience is limited. I tried to do > > gdb > run -vvvvvvvvv > > but it took like 10 minutes for asterisk to fully start, and even then, > it did not seem to be starting correctly. > > What is the best way to get a back trace from asterisk?Look here: http://www.voip-info.org/tiki-index.php?page=Asterisk debugging Cheers, Philipp
It is producing 2 core files. Here are the backtraces of each:
#0 0x402d5156 in create_addr (r=0x81a9658, peer=0xbd7fdd24
"9258004633") at chan_sip.c:968
968 memcpy(&r->sa.sin_addr, hp->h_addr,
sizeof(r->sa.sin_addr));
(gdb) bt
#0 0x402d5156 in create_addr (r=0x81a9658, peer=0xbd7fdd24
"9258004633") at chan_sip.c:968
#1 0x402e88b7 in sip_request (type=0xbd7fe524 "SIP", format=4,
data=0xbd7fe2d4) at chan_sip.c:6229
#2 0x0805a1fd in ast_request (type=0xbd7fe524 "SIP", format=68,
data=0xbd7fe2d4) at channel.c:1767
#3 0x40524f4f in dial_exec (chan=0x81b2b88, data=0xbd7fe854) at
app_dial.c:651
#4 0x08064f8c in pbx_exec (c=0x81b2b88, app=0x80e5f88, data=0xbd7fe854,
newstack=1) at pbx.c:413
#5 0x08067043 in pbx_extension_helper (c=0x81b2b88, context=0x81b2ce0
"macro-sipexten", exten=0x81b2dd4 "s", priority=5,
callerid=0x814e908 "9252533152", action=1) at pbx.c:1195
#6 0x0806dcee in ast_spawn_extension (c=0x81b2b88, context=0x81b2ce0
"macro-sipexten", exten=0x81b2dd4 "s", priority=5,
callerid=0x814e908 "9252533152") at pbx.c:1679
#7 0x406e24a8 in macro_exec (chan=0x81b2b88, data=0xbd7ff2a4) at
app_macro.c:140
#8 0x08064f8c in pbx_exec (c=0x81b2b88, app=0x8145e70, data=0xbd7ff2a4,
newstack=1) at pbx.c:413
#9 0x08067043 in pbx_extension_helper (c=0x81b2b88, context=0x81b2ce0
"macro-sipexten", exten=0x81b2dd4 "s", priority=1,
callerid=0x814e908 "9252533152", action=1) at pbx.c:1195
#10 0x08067d7d in ast_pbx_run (c=0x81b2b88) at pbx.c:1679
#11 0x404d0480 in ss_thread (data=0x81b2b88) at chan_zap.c:4395
#12 0x400210ba in pthread_start_thread () from /lib/libpthread.so.0
#0 0x400c8781 in kill () from /lib/libc.so.6
(gdb) bt
#0 0x400c8781 in kill () from /lib/libc.so.6
#1 0x40023e5e in pthread_kill () from /lib/libpthread.so.0
#2 0x40024339 in raise () from /lib/libpthread.so.0
#3 0x400c9be1 in abort () from /lib/libc.so.6
#4 0x4010fa30 in malloc_set_state () from /lib/libc.so.6
#5 0x4010da29 in free () from /lib/libc.so.6
#6 0x080968ba in el_end (el=0x80d62f8) at el.c:125
#7 0x0808572c in quit_handler (num=15, nice=0, safeshutdown=1,
restart=0) at asterisk.c:552
#8 0x08088531 in __quit_handler (num=15) at asterisk.c:600
#9 0x40023f54 in pthread_sighandler () from /lib/libpthread.so.0
#10 0x400c86b8 in sigaction () from /lib/libc.so.6
#11 0x08084daf in listener (unused=0x0) at asterisk.c:298
#12 0x400210ba in pthread_start_thread () from /lib/libpthread.so.0
Looks to me like its in no way related to the dbodbc stuff...
Let me know if there is anything else you need me to do.
On Fri, 2004-04-30 at 13:04, Philipp von Klitzing wrote:> Hi!
>
> > bt = Back trace?
> >
> > My gdb experience is limited. I tried to do
> >
> > gdb
> > run -vvvvvvvvv
> >
> > but it took like 10 minutes for asterisk to fully start, and even
then,
> > it did not seem to be starting correctly.
> >
> > What is the best way to get a back trace from asterisk?
>
> Look here:
> http://www.voip-info.org/tiki-index.php?page=Asterisk debugging
>
> Cheers, Philipp
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
WOAH!!! You using latest cvs? bkw> -----Original Message----- > From: asterisk-users-admin@lists.digium.com [mailto:asterisk-users- > admin@lists.digium.com] On Behalf Of Mike Machado > Sent: Friday, April 30, 2004 5:39 PM > To: asterisk-users@lists.digium.com > Subject: RE: [Asterisk-Users] app_dbodbc segfault > > > It is producing 2 core files. Here are the backtraces of each: > > > #0 0x402d5156 in create_addr (r=0x81a9658, peer=0xbd7fdd24 > "9258004633") at chan_sip.c:968 > 968 memcpy(&r->sa.sin_addr, hp->h_addr, > sizeof(r->sa.sin_addr)); > (gdb) bt > #0 0x402d5156 in create_addr (r=0x81a9658, peer=0xbd7fdd24 > "9258004633") at chan_sip.c:968 > #1 0x402e88b7 in sip_request (type=0xbd7fe524 "SIP", format=4, > data=0xbd7fe2d4) at chan_sip.c:6229 > #2 0x0805a1fd in ast_request (type=0xbd7fe524 "SIP", format=68, > data=0xbd7fe2d4) at channel.c:1767 > #3 0x40524f4f in dial_exec (chan=0x81b2b88, data=0xbd7fe854) at > app_dial.c:651 > #4 0x08064f8c in pbx_exec (c=0x81b2b88, app=0x80e5f88, data=0xbd7fe854, > newstack=1) at pbx.c:413 > #5 0x08067043 in pbx_extension_helper (c=0x81b2b88, context=0x81b2ce0 > "macro-sipexten", exten=0x81b2dd4 "s", priority=5, > callerid=0x814e908 "9252533152", action=1) at pbx.c:1195 > #6 0x0806dcee in ast_spawn_extension (c=0x81b2b88, context=0x81b2ce0 > "macro-sipexten", exten=0x81b2dd4 "s", priority=5, > callerid=0x814e908 "9252533152") at pbx.c:1679 > #7 0x406e24a8 in macro_exec (chan=0x81b2b88, data=0xbd7ff2a4) at > app_macro.c:140 > #8 0x08064f8c in pbx_exec (c=0x81b2b88, app=0x8145e70, data=0xbd7ff2a4, > newstack=1) at pbx.c:413 > #9 0x08067043 in pbx_extension_helper (c=0x81b2b88, context=0x81b2ce0 > "macro-sipexten", exten=0x81b2dd4 "s", priority=1, > callerid=0x814e908 "9252533152", action=1) at pbx.c:1195 > #10 0x08067d7d in ast_pbx_run (c=0x81b2b88) at pbx.c:1679 > #11 0x404d0480 in ss_thread (data=0x81b2b88) at chan_zap.c:4395 > #12 0x400210ba in pthread_start_thread () from /lib/libpthread.so.0 > > > > > #0 0x400c8781 in kill () from /lib/libc.so.6 > (gdb) bt > #0 0x400c8781 in kill () from /lib/libc.so.6 > #1 0x40023e5e in pthread_kill () from /lib/libpthread.so.0 > #2 0x40024339 in raise () from /lib/libpthread.so.0 > #3 0x400c9be1 in abort () from /lib/libc.so.6 > #4 0x4010fa30 in malloc_set_state () from /lib/libc.so.6 > #5 0x4010da29 in free () from /lib/libc.so.6 > #6 0x080968ba in el_end (el=0x80d62f8) at el.c:125 > #7 0x0808572c in quit_handler (num=15, nice=0, safeshutdown=1, > restart=0) at asterisk.c:552 > #8 0x08088531 in __quit_handler (num=15) at asterisk.c:600 > #9 0x40023f54 in pthread_sighandler () from /lib/libpthread.so.0 > #10 0x400c86b8 in sigaction () from /lib/libc.so.6 > #11 0x08084daf in listener (unused=0x0) at asterisk.c:298 > #12 0x400210ba in pthread_start_thread () from /lib/libpthread.so.0 > > > Looks to me like its in no way related to the dbodbc stuff... > > Let me know if there is anything else you need me to do. > > > > On Fri, 2004-04-30 at 13:04, Philipp von Klitzing wrote: > > Hi! > > > > > bt = Back trace? > > > > > > My gdb experience is limited. I tried to do > > > > > > gdb > > > run -vvvvvvvvv > > > > > > but it took like 10 minutes for asterisk to fully start, and even > then, > > > it did not seem to be starting correctly. > > > > > > What is the best way to get a back trace from asterisk? > > > > Look here: > > http://www.voip-info.org/tiki-index.php?page=Asterisk debugging > > > > Cheers, Philipp > > > > _______________________________________________ > > Asterisk-Users mailing list > > Asterisk-Users@lists.digium.com > > http://lists.digium.com/mailman/listinfo/asterisk-users > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
Yes, as of this morning. On Fri, 2004-04-30 at 15:56, brian wrote:> WOAH!!! You using latest cvs? > > bkw > > > -----Original Message----- > > From: asterisk-users-admin@lists.digium.com [mailto:asterisk-users- > > admin@lists.digium.com] On Behalf Of Mike Machado > > Sent: Friday, April 30, 2004 5:39 PM > > To: asterisk-users@lists.digium.com > > Subject: RE: [Asterisk-Users] app_dbodbc segfault > > > > > > It is producing 2 core files. Here are the backtraces of each: > > > > > > #0 0x402d5156 in create_addr (r=0x81a9658, peer=0xbd7fdd24 > > "9258004633") at chan_sip.c:968 > > 968 memcpy(&r->sa.sin_addr, hp->h_addr, > > sizeof(r->sa.sin_addr)); > > (gdb) bt > > #0 0x402d5156 in create_addr (r=0x81a9658, peer=0xbd7fdd24 > > "9258004633") at chan_sip.c:968 > > #1 0x402e88b7 in sip_request (type=0xbd7fe524 "SIP", format=4, > > data=0xbd7fe2d4) at chan_sip.c:6229 > > #2 0x0805a1fd in ast_request (type=0xbd7fe524 "SIP", format=68, > > data=0xbd7fe2d4) at channel.c:1767 > > #3 0x40524f4f in dial_exec (chan=0x81b2b88, data=0xbd7fe854) at > > app_dial.c:651 > > #4 0x08064f8c in pbx_exec (c=0x81b2b88, app=0x80e5f88, data=0xbd7fe854, > > newstack=1) at pbx.c:413 > > #5 0x08067043 in pbx_extension_helper (c=0x81b2b88, context=0x81b2ce0 > > "macro-sipexten", exten=0x81b2dd4 "s", priority=5, > > callerid=0x814e908 "9252533152", action=1) at pbx.c:1195 > > #6 0x0806dcee in ast_spawn_extension (c=0x81b2b88, context=0x81b2ce0 > > "macro-sipexten", exten=0x81b2dd4 "s", priority=5, > > callerid=0x814e908 "9252533152") at pbx.c:1679 > > #7 0x406e24a8 in macro_exec (chan=0x81b2b88, data=0xbd7ff2a4) at > > app_macro.c:140 > > #8 0x08064f8c in pbx_exec (c=0x81b2b88, app=0x8145e70, data=0xbd7ff2a4, > > newstack=1) at pbx.c:413 > > #9 0x08067043 in pbx_extension_helper (c=0x81b2b88, context=0x81b2ce0 > > "macro-sipexten", exten=0x81b2dd4 "s", priority=1, > > callerid=0x814e908 "9252533152", action=1) at pbx.c:1195 > > #10 0x08067d7d in ast_pbx_run (c=0x81b2b88) at pbx.c:1679 > > #11 0x404d0480 in ss_thread (data=0x81b2b88) at chan_zap.c:4395 > > #12 0x400210ba in pthread_start_thread () from /lib/libpthread.so.0 > > > > > > > > > > #0 0x400c8781 in kill () from /lib/libc.so.6 > > (gdb) bt > > #0 0x400c8781 in kill () from /lib/libc.so.6 > > #1 0x40023e5e in pthread_kill () from /lib/libpthread.so.0 > > #2 0x40024339 in raise () from /lib/libpthread.so.0 > > #3 0x400c9be1 in abort () from /lib/libc.so.6 > > #4 0x4010fa30 in malloc_set_state () from /lib/libc.so.6 > > #5 0x4010da29 in free () from /lib/libc.so.6 > > #6 0x080968ba in el_end (el=0x80d62f8) at el.c:125 > > #7 0x0808572c in quit_handler (num=15, nice=0, safeshutdown=1, > > restart=0) at asterisk.c:552 > > #8 0x08088531 in __quit_handler (num=15) at asterisk.c:600 > > #9 0x40023f54 in pthread_sighandler () from /lib/libpthread.so.0 > > #10 0x400c86b8 in sigaction () from /lib/libc.so.6 > > #11 0x08084daf in listener (unused=0x0) at asterisk.c:298 > > #12 0x400210ba in pthread_start_thread () from /lib/libpthread.so.0 > > > > > > Looks to me like its in no way related to the dbodbc stuff... > > > > Let me know if there is anything else you need me to do. > > > > > > > > On Fri, 2004-04-30 at 13:04, Philipp von Klitzing wrote: > > > Hi! > > > > > > > bt = Back trace? > > > > > > > > My gdb experience is limited. I tried to do > > > > > > > > gdb > > > > run -vvvvvvvvv > > > > > > > > but it took like 10 minutes for asterisk to fully start, and even > > then, > > > > it did not seem to be starting correctly. > > > > > > > > What is the best way to get a back trace from asterisk? > > > > > > Look here: > > > http://www.voip-info.org/tiki-index.php?page=Asterisk debugging > > > > > > Cheers, Philipp > > > > > > _______________________________________________ > > > Asterisk-Users mailing list > > > Asterisk-Users@lists.digium.com > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > To UNSUBSCRIBE or update options visit: > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > _______________________________________________ > > Asterisk-Users mailing list > > Asterisk-Users@lists.digium.com > > http://lists.digium.com/mailman/listinfo/asterisk-users > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
On Fri, 2004-04-30 at 20:05, Mike Machado wrote:> Is anyone out there using app_dbodbc > (http://www.bkw.org/~brian/app_dbodbc.c)? Any problems with it?I use it & works for me, no segfaults. I checked the version of the file & it's identical to yours (although I used a different URL: http://asterisk.bkw.org/other/app_dbodbc.c) I am currently rebuilding on latest CVS, so hope that I don't encounter the same problems ;)> For what its worth, I ported app_dbodbc.c to a new app_dbmysql.c and > created MySQLget, MySQLput, MySQLdel and MySQLdeltree, and experience > the exact same problem. If anyone wants the app_dbmysql.c, let me know.I would be interested in this - saves the overheads of going via ODBC. Pls post to a website somewhere. F