[asterisk-dev] write my self app. Debug

[Matt Fredrickson]

On Mon, Sep 17, 2018 at 9:00 AM info at magnussolution.com
<info at magnussolution.com> wrote:
>
> Hi, sorry bother you.
>
> I get a new backtrace
>
> Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00007f82ad124c80 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #0  0x00007f82ad124c80 in pthread_mutex_lock () from /lib64/libpthread.so.0
> No symbol table info available.
> #1  0x0000000000533c38 in __ast_pthread_mutex_lock (filename=<optimized out>, lineno=<optimized out>, func=<optimized out>, mutex_name=<optimized out>, t=<optimized out>) at lock.c:315
> No locals.
> #2  0x00007f829927aa12 in ast_odbc_release_obj (obj=obj at entry=0x7f81e8021900) at res_odbc.c:724
>         class = 0x0
>         __PRETTY_FUNCTION__ = "ast_odbc_release_obj"
> #3  0x00007f81c2aee0b1 in dial_exec (chan=<optimized out>, data=0x7f81c3e85ae0 “\"SIP/magnus\"") at app_mbilling.c:4220
>
>
>
>
> My code line 4219 - 4222:
>
> 4219               if(obj){
> 4220 ast_odbc_release_obj(obj);
> 4221 obj = NULL;
> 4222 }

Is it possible that our released the object multiple times?  If class
= 0x0 at the time of that lock in the release, that would indicate
that the obj->parent field has been set to 0x0 already by
somebody/something earlier.

Not sure how much more that can be helped here since you're asking
coding advice about a module that we can't see the source to.

Best wishes,
Matthew Fredrickson

>
>
> Please help me.
>
> Best regards
>
>
>
>
> On 12 Sep 2018, at 20:10, info at magnussolution.com wrote:
>
> thanks for you help.
>
>
> I try use backtrace. But I no a expert.
>
> I using cents 7 64x
>
> gdb -se "asterisk" -ex "bt full" -ex "thread apply all bt" --batch -c core.13414 > /tmp/backtrace.txt
>
> warning: exec file is newer than core file.
> Missing separate debuginfo for /usr/lib64/libmyodbc5.so
>
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Missing separate debuginfo for /usr/lib64/libmyodbc5.so
> Core was generated by `asterisk -vvvvvvvg'.
> Program terminated with signal 11, Segmentation fault.
> #0  ast_odbc_release_obj (obj=0x0) at res_odbc.c:712
> 712 struct odbc_class *class = obj->parent;
>
>
> to use ODBC on centos7 and mariaDB 10 I install it
>
> yum -y remove mysql-connector-odbc
> yum -y localinstall --nogpgcheck http://dev.mysql.com/get/Downloads/Connector-ODBC/5.3/mysql-connector-odbc-5.3.11-1.el7.x86_64.rpm
> ln -s /usr/lib64/libmyodbc5w.so  /usr/lib64/libmyodbc5.so
>
>
>
> On 12 Sep 2018, at 19:28, Alex Villací­s Lasso <a_villacis at palosanto.com> wrote:
>
> El 12/9/18 a las 14:33, info at magnussolution.com escribió:
>
> that’s correct. I wrote a ael context with func_odbc and this work very well.
>
> But, using my app_mbilling.c work more faster than ael and func_odbc.
>
> example:
> agi 15 CPS
> ael-func_odbc 30 CPS
> native application 50 CPS
>
>
> Have you tried yet FastAGI? Ordinary AGI is slowed down by the spawning of an entire process per call. FastAGI just requires a daemon that listens to requests on a TCP/IP port. This is way less invasive than writing a whole new Asterisk application in C. Any bottlenecks would now be located in the FastAGI server and could be tuned without touching the Asterisk core.
>
> As an aside, just a wild guess, but I think the crashes could be due to one or more race conditions, and the proper locking required to solve them would slow down your C application to the ael-func_odbc level.
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Astricon is coming up October 9-11!  Signup is available at: https://www.asterisk.org/community/astricon-user-conference
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Astricon is coming up October 9-11!  Signup is available at: https://www.asterisk.org/community/astricon-user-conference
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Astricon is coming up October 9-11!  Signup is available at: https://www.asterisk.org/community/astricon-user-conference
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev



-- 
Matthew Fredrickson
Digium - A Sangoma Company | Asterisk Project Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA