[asterisk-dev] write my self app. Debug

info at magnussolution.com info at magnussolution.com
Mon Sep 17 17:13:57 CDT 2018 

hi, you are correct. I try release two time.

best regards



> On 17 Sep 2018, at 18:48, Matt Fredrickson <creslin at digium.com> wrote:
> 
> On Mon, Sep 17, 2018 at 9:00 AM info at magnussolution.com <mailto:info at magnussolution.com>
> <info at magnussolution.com <mailto: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 <http://www.api-digital.com/> --
>> 
>> Astricon is coming up October 9-11!  Signup is available at: https://www.asterisk.org/community/astricon-user-conference <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 <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
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com <http://www.api-digital.com/> --
> 
> Astricon is coming up October 9-11!  Signup is available at: https://www.asterisk.org/community/astricon-user-conference <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 <http://lists.digium.com/mailman/listinfo/asterisk-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180917/424d6fde/attachment-0001.html>

More information about the asterisk-dev mailing list