[Asterisk-bsd] Segfault on FBSD 7.2 and Asterisk 1.4.26.2

Chris Coleman chrisc at vmunix.com
Mon Feb 22 09:28:38 CST 2010 

I haven't heard back from you.  It is still core dumping.

Here is another trace:

(gdb) bt
#0  0x0000000801658460 in SQLGetData () from /usr/local/lib/libodbc.so.1
#1  0x00000008076261b4 in acf_odbc_read (chan=0x806735000, cmd=Variable
"cmd" is not available.
) at func_odbc.c:330
#2  0x000000000046939d in pbx_retrieve_variable ()
#3  0x000000000046a9b0 in ast_extension_state ()
#4  0x000000000046ae73 in ast_spawn_extension ()
#5  0x000000000046e091 in ast_context_lockmacro ()
#6  0x000000000046f549 in ast_pbx_outgoing_exten ()
#7  0x0000000000496b23 in ast_wait_for_input ()
#8  0x0000000800c064d1 in pthread_getprio () from /lib/libthr.so.3
#9  0x00007ffffef4e000 in ?? ()
Cannot access memory at address 0x7ffffefca000
(gdb) bt full
#0  0x0000000801658460 in SQLGetData () from /usr/local/lib/libodbc.so.1
No symbol table info available.
#1  0x00000008076261b4 in acf_odbc_read (chan=0x806735000, cmd=Variable
"cmd" is not available.
) at func_odbc.c:330
        coldata =
"\b\000\000\000\000\000\000\000?\234?\000\b\000\000\000\002\000\000\000\000\000\000\000??\000\001\b\000\000\000
\000\000\0000\000\000\000P7???\177\000\000\2006???\177\000\000`?\006\001\b\000\000\000\200jg\002\b\000\000\000??\000\001\b\000\000\000`?\006\001\b\000\000\000\001",
'\0' <repeats 15 times>,
"\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\206l?\000\b\000\000\000n\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000T\000\000\000\000\000\000\000\020\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\206l?\000\b\000\000\000`?\006\001\b\000\000\000?7???\177\000\000?x???\177\000\000`?\006\001\b"...
        obj = (struct odbc_obj *) 0x802676e40
        query = Variable "query" is not available.
(gdb)


On Thu, Feb 18, 2010 at 7:36 AM, Chris Coleman <chrisc at vmunix.com> wrote:

> K, it crashed again.  Here is the Backtrace.
>
> -Chris
>
>
> (gdb) bt
> #0  0x00000008016546cf in SQLFreeEnv () from /usr/local/lib/libodbc.so.1
> #1  0x0000000801654dec in SQLFreeHandle () from /usr/local/lib/libodbc.so.1
> #2  0x00000008076259af in acf_odbc_write () from
> /usr/local/lib/asterisk/modules/func_odbc.so
> #3  0x000000000046bbeb in pbx_builtin_setvar_helper (chan=0x80672a000,
>     name=0x7fffff2311e0 "ODBC_WRITE_LOCAL(insert into call_log
> (clid,phone_number_id,uniqueid,duration,action,arrangement,date) values
> ('18453562190','7189775916','1266467353.1659','0','Original Call
> 7189775916','1',now()))", value=0x7fffff2312a7 "confirmed") at pbx.c:5884
> #4  0x000000000046bfb2 in pbx_builtin_setvar (chan=0x80672a000,
> data=Variable "data" is not available.
> ) at pbx.c:5957
> #5  0x0000000000467e2a in pbx_exec (c=0x80672a000, app=0x8010500d0,
> data=0x7fffff233470) at pbx.c:536
> #6  0x000000000046a9b5 in pbx_extension_helper (c=0x80672a000,
> con=0x7fffff231470, context=0x80672a230 "macro-podlinez-stat",
> exten=0x80672a280 "s", priority=1, label=Variable "label" is not available.
> ) at pbx.c:1863
> #7  0x000000000046ae03 in ast_spawn_extension (c=Variable "c" is not
> available.
> ) at pbx.c:2283
> #8  0x0000000803bc8a0b in _macro_exec () from
> /usr/local/lib/asterisk/modules/app_macro.so
> #9  0x0000000000467e2a in pbx_exec (c=0x80672a000, app=0x8026760a0,
> data=0x7fffff2388e0) at pbx.c:536
> #10 0x000000000046a9b5 in pbx_extension_helper (c=0x80672a000,
> con=0x7fffff2368e0, context=0x80672a230 "macro-podlinez-stat",
> exten=0x80672a280 "s", priority=4, label=Variable "label" is not available.
> ) at pbx.c:1863
> #11 0x000000000046ae03 in ast_spawn_extension (c=Variable "c" is not
> available.
> ) at pbx.c:2283
> #12 0x000000000046e021 in __ast_pbx_run (c=0x80672a000) at pbx.c:2373
> #13 0x000000000046f4d9 in pbx_thread (data=Variable "data" is not
> available.
> ) at pbx.c:2599
> #14 0x00000000004968b3 in dummy_start (data=Variable "data" is not
> available.
> ) at utils.c:856
> #15 0x0000000800c054d1 in pthread_getprio () from /lib/libthr.so.3
> #16 0x00007fffff1bf000 in ?? ()
> Cannot access memory at address 0x7fffff23b000
>
>
> (gdb) bt full
> #0  0x00000008016546cf in SQLFreeEnv () from /usr/local/lib/libodbc.so.1
> No symbol table info available.
> #1  0x0000000801654dec in SQLFreeHandle () from /usr/local/lib/libodbc.so.1
> No symbol table info available.
> #2  0x00000008076259af in acf_odbc_write () from
> /usr/local/lib/asterisk/modules/func_odbc.so
> No symbol table info available.
> #3  0x000000000046bbeb in pbx_builtin_setvar_helper (chan=0x80672a000,
>     name=0x7fffff2311e0 "ODBC_WRITE_LOCAL(insert into call_log
> (clid,phone_number_id,uniqueid,duration,action,arrangement,date) values
> ('18453562190','7189775916','1266467353.1659','0','Original Call
> 7189775916','1',now()))", value=0x7fffff2312a7 "confirmed") at pbx.c:5884
>         curelm = Variable "curelm" is not available.
> (gdb)
>
>
>
>
> On Mon, Feb 15, 2010 at 9:52 PM, Max Khon <fjoe at samodelkin.net> wrote:
>
>> Hello, Chris!
>>
>> On Tue, Feb 16, 2010 at 5:12 AM, Chris Coleman <chrisc at vmunix.com> wrote:
>>
>>
>>> I'm running Asterisk on FBSD 7.2 using only SIP incoming DIDs.  I'm also
>>> using unixODBC to connect to a postgres DB.   I'm running asterisk from
>>> ports.
>>>
>>> Here is my system info:
>>>
>>> Asterisk 1.4.26.2, Copyright (C) 1999 - 2008 Digium, Inc. and others.
>>>
>>> FreeBSD kvm10.podlinez.lan 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri
>>> Oct  2 08:22:32 UTC 2009     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
>>>  amd64
>>>
>>>
>>> I'm getting very frequent core dumps, so I've rebuilt asterisk with -g3
>>> to enable debug.  I've also ran it with valgrind and attached it to the
>>> e-mail.
>>>
>>> Here is the Summary:
>>>
>>> ==30746==    definitely lost: 28,597 bytes in 75 blocks
>>> ==30746==    indirectly lost: 143,559 bytes in 308 blocks
>>> ==30746==      possibly lost: 6,119,992 bytes in 98,335 blocks
>>> ==30746==    still reachable: 3,169,594 bytes in 37,091 blocks
>>> ==30746==         suppressed: 0 bytes in 0 blocks
>>>
>>> It seems like it has a memory leak that is causing the problem.
>>>
>>> In my experience, it dies trying to do a DB call.
>>>
>>
>> The leak does not seem to be big enough to cause any problems. Do you have
>> a core files and can you show the stack trace?
>>
>> Max
>>
>>
>
>
> --
> Chris Coleman --  http://Podlinez.com
>



-- 
Chris Coleman --  http://Podlinez.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-bsd/attachments/20100222/0715aef1/attachment.htm

More information about the Asterisk-BSD mailing list