[asterisk-bugs] [JIRA] (ASTERISK-30502) asterisk crashes when loading res_odbc

Philip de Orleans (JIRA) noreply at issues.asterisk.org
Mon Apr 24 15:26:03 CDT 2023


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

Philip de Orleans commented on ASTERISK-30502:
----------------------------------------------

valgrind
[Apr 24 20:23:06] NOTICE[154068]: loader.c:2415 load_modules: 285 modules will be loaded.
 Loading extconfig.
[ Initializing Custom Configuration Options ]
  == extconfig => (Configuration)
 Loading logger.
  == logger => (Logger)
 Loading res_curl.so.
  == res_curl.so => (cURL Resource Module)
 Loading res_odbc_transaction.so.
  == Registered application 'ODBC_Commit'
  == Registered application 'ODBC_Rollback'
  == Registered custom function 'ODBC'
  == res_odbc_transaction.so => (ODBC transaction resource)
 Loading res_odbc.so.
==154068== Invalid read of size 1
==154068==    at 0x4C3F114: strcmp (vg_replace_strmem.c:924)
==154068==    by 0x2E625ED5: ??? (in /usr/lib64/libodbc.so.2.0.0)
==154068==    by 0x2E6289D0: SQLConnect (in /usr/lib64/libodbc.so.2.0.0)
==154068==    by 0x2E4142F1: odbc_obj_connect (res_odbc.c:1052)
==154068==    by 0x2E413A52: _ast_odbc_request_obj2 (res_odbc.c:935)
==154068==    by 0x2E413E57: _ast_odbc_request_obj (res_odbc.c:983)
==154068==    by 0x2E4133B4: odbc_register_class (res_odbc.c:796)
==154068==    by 0x2E412CE7: load_odbc_config (res_odbc.c:696)
==154068==    by 0x2E41480F: load_module (res_odbc.c:1123)
==154068==    by 0x51EC4A: start_resource (loader.c:1728)
==154068==    by 0x51F6B6: start_resource_attempt (loader.c:1915)
==154068==    by 0x520060: start_resource_list (loader.c:2012)
==154068==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==154068== 
==154068== 
==154068== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==154068==  Access not within mapped region at address 0x0
==154068==    at 0x4C3F114: strcmp (vg_replace_strmem.c:924)
==154068==    by 0x2E625ED5: ??? (in /usr/lib64/libodbc.so.2.0.0)
==154068==    by 0x2E6289D0: SQLConnect (in /usr/lib64/libodbc.so.2.0.0)
==154068==    by 0x2E4142F1: odbc_obj_connect (res_odbc.c:1052)
==154068==    by 0x2E413A52: _ast_odbc_request_obj2 (res_odbc.c:935)
==154068==    by 0x2E413E57: _ast_odbc_request_obj (res_odbc.c:983)
==154068==    by 0x2E4133B4: odbc_register_class (res_odbc.c:796)
==154068==    by 0x2E412CE7: load_odbc_config (res_odbc.c:696)
==154068==    by 0x2E41480F: load_module (res_odbc.c:1123)
==154068==    by 0x51EC4A: start_resource (loader.c:1728)
==154068==    by 0x51F6B6: start_resource_attempt (loader.c:1915)
==154068==    by 0x520060: start_resource_list (loader.c:2012)
==154068==  If you believe this happened as a result of a stack
==154068==  overflow in your program's main thread (unlikely but
==154068==  possible), you can try to increase the size of the
==154068==  main thread stack using the --main-stacksize= flag.
==154068==  The main thread stack size used in this run was 8388608.
==154068== 
==154068== HEAP SUMMARY:
==154068==     in use at exit: 2,137,223 bytes in 9,295 blocks
==154068==   total heap usage: 17,957 allocs, 8,662 frees, 8,526,398 bytes allocated
==154068== 
==154068== LEAK SUMMARY:
==154068==    definitely lost: 0 bytes in 0 blocks
==154068==    indirectly lost: 0 bytes in 0 blocks
==154068==      possibly lost: 433,615 bytes in 1,082 blocks
==154068==    still reachable: 1,703,608 bytes in 8,213 blocks
==154068==                       of which reachable via heuristic:
==154068==                         length64           : 164,272 bytes in 197 blocks
==154068==                         newarray           : 1,536 bytes in 16 blocks
==154068==         suppressed: 0 bytes in 0 blocks
==154068== Rerun with --leak-check=full to see details of leaked memory
==154068== 
==154068== For lists of detected and suppressed errors, rerun with: -s
==154068== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

> asterisk crashes when loading res_odbc
> --------------------------------------
>
>                 Key: ASTERISK-30502
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30502
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_odbc
>    Affects Versions: 18.11.2
>         Environment: Linux Centos 7 and 8
>            Reporter: Philip de Orleans
>         Attachments: asterisk-crash.txt
>
>
> I use mariadb and the odbc connector. The command Isql works fine. when I try to load res_odbc, it crashes in both operating systems and with two versions of the driver. I have a trace, will upload it next



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



More information about the asterisk-bugs mailing list