[asterisk-bugs] [JIRA] (ASTERISK-25176) Asterisk segfault on reload res_odbc.so

[Tzafrir Cohen (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=227433#comment-227433 ] 

Tzafrir Cohen commented on ASTERISK-25176:
------------------------------------------

I have the same issue on a Centos 7 system with Asterisk 13.1-cert2. I get a similar backtrace.

The immediate cause of the crash:  mysql_get_character_set_info() assumes that the MYSQL struct is initialized, and specifically has a valid charset.

mysql->charset is initialized in mysql_init(). However, on the second time it is called, mysql_init exits immediately: it begins with:
{code}
   1722   if (mysql_server_init(0, NULL, NULL))
   1723     return 0;
{code}
mysql_server_init, if called the second time, will call my_thread_init() instead of the rest of the initializations. my_thread_init() bails out immediately:
{code}
    309   if (!my_thread_global_init_done)
    310     return 1; /* cannot proceed with unintialized library */
{code}

So it seems that a call to my_thread_global_init() is missing somewhere. Well, that's the low-level part.

> Asterisk segfault on reload res_odbc.so
> ---------------------------------------
>
>                 Key: ASTERISK-25176
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25176
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_odbc
>    Affects Versions: 13.1.0, 13.4.0
>         Environment: CentOS 7.0
>            Reporter: Marty Riedling
>            Assignee: Rusty Newton
>
> Asterisk-13.1-cert2 (as well as 13.4) segfault on a reload res_odbc.so
> With a backtrace of:
> {noformat}
> (gdb)
> #0  0x00007f402ca959cb in mysql_get_character_set_info () from /usr/lib64/mysql/libmysqlclient.so.18
> #1  0x00007f402cf8e9e5 in myodbc_do_connect () from /usr/lib64/libmyodbc5.so
> #2  0x00007f402cf8edd1 in MySQLConnect () from /usr/lib64/libmyodbc5.so
> #3  0x00007f402fb9b3a3 in SQLConnect () from /lib64/libodbc.so.2
> #4  0x00007f402fdfb1c4 in odbc_obj_connect (obj=0x7f3fc4005158) at res_odbc.c:1553
> #5  0x00007f402fdfa655 in _ast_odbc_request_obj2 (name=0x7f3fc4005580 "asteriskcdrdb", flags=..., file=0x7f402fdfc434 "res_odbc.c",
>     function=0x7f402fdfd700 <__PRETTY_FUNCTION__.16193> "odbc_register_class", lineno=1043) at res_odbc.c:1375
> #6  0x00007f402fdfab02 in _ast_odbc_request_obj (name=0x7f3fc4005580 "asteriskcdrdb", check=0, file=0x7f402fdfc434 "res_odbc.c",
>     function=0x7f402fdfd700 <__PRETTY_FUNCTION__.16193> "odbc_register_class", lineno=1043) at res_odbc.c:1448
> #7  0x00007f402fdf9066 in odbc_register_class (class=0x7f3fc4005578, preconnect=-1) at res_odbc.c:1043
> #8  0x00007f402fdf8981 in load_odbc_config () at res_odbc.c:927
> #9  0x00007f402fdfc0cc in reload () at res_odbc.c:1821
> #10 0x000000000052bbf6 in ast_module_reload (name=0x7f3fc4006c8e "res_odbc.so") at loader.c:918
> #11 0x00000000004c90aa in handle_reload (e=0x887e98 <cli_cli+3000>, cmd=-4, a=0x7f40440b56f0) at cli.c:294
> #12 0x00000000004d0a8a in ast_cli_command_full (uid=-1, gid=-1, fd=16, s=0x7f40440b59c8 "module reload res_odbc.so") at cli.c:2719
> #13 0x00007f3f90e5d713 in cli_alias_passthrough (e=0x1b441e8, cmd=-4, a=0x7f40440b6360) at res_clialiases.c:148
> #14 0x00000000004d0a8a in ast_cli_command_full (uid=0, gid=0, fd=16, s=0x7f40440b6640 "reload res_odbc.so") at cli.c:2719
> #15 0x00000000004d0bc6 in ast_cli_command_multiple_full (uid=0, gid=0, fd=16, size=19, s=0x7f40440b6a90 "reload res_odbc.so") at cli.c:2742
> #16 0x0000000000450db2 in netconsole (vconsole=0x8b0680 <consoles>) at asterisk.c:1521
> #17 0x00000000005e0e40 in dummy_start (data=0x7f40280008f0) at utils.c:1232
> #18 0x00007f4049146df5 in start_thread () from /lib64/libpthread.so.0
> #19 0x00007f40484ec1ad in clone () from /lib64/libc.so.6
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)