[ODBC-339] Segfault in SQLPrepare() -> MADB_SetIrdRecord() -> strdup() Created: 2021-09-06  Updated: 2021-09-28  Resolved: 2021-09-28

Status: Closed
Project: MariaDB Connector/ODBC
Component/s: General
Affects Version/s: None
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Damjan Jovanovic Assignee: Lawrin Novitsky
Resolution: Not a Bug Votes: 0
Labels: crash
Environment:

Debian 10.10 Linux 4.19.0-17-amd64


 Description   

After running Asterisk (http://www.asterisk.org) with the MariaDB ODBC connector built from recent Git master (at commit 8e057ce57e21fafadddf73a9124038191858c97c) for some time, it crashes. Multiple Asterisk versions (13, 16) crash. MySQL ODBC connector on CentOS also crashes but I am not sure if that's the same problem. Here is the stack trace for MariaDB's connector:

#0  0x00007f0a9fc5c105 in _int_malloc (av=av@entry=0x7f0a6c000020, bytes=bytes@entry=14) at malloc.c:4033
 
#1  0x00007f0a9fc5d56a in __GI___libc_malloc (bytes=bytes@entry=14) at malloc.c:3057
 
#2  0x00007f0a9fc60dba in __GI___strdup (s=s@entry=0x7f0a6c17de68 "timers_min_se") at strdup.c:42
 
#3  0x00007f0a13716957 in MADB_SetIrdRecord (Field=0x7f0a6c32d808, Record=0x7f0a6cac4fb8, Stmt=<optimized out>) at /opt/mariadb-connector-odbc/ma_desc.c:189
 
#4  0x00007f0a13716957 in MADB_SetIrdRecord (Stmt=<optimized out>, Record=0x7f0a6cac4fb8, Field=0x7f0a6c32d808) at /opt/mariadb-connector-odbc/ma_desc.c:175
 
#5  0x00007f0a137174ff in MADB_DescSetIrdMetadata (Stmt=Stmt@entry=0x7f0a6c39d6e0, Fields=<optimized out>, NumFields=NumFields@entry=108) at /opt/mariadb-connector-odbc/ma_desc.c:324
 
#6  0x00007f0a1371376b in MADB_RegularPrepare (Stmt=Stmt@entry=0x7f0a6c39d6e0) at /opt/mariadb-connector-odbc/ma_statement.c:506
 
#7  0x00007f0a13713adf in MADB_StmtPrepare (Stmt=0x7f0a6c39d6e0, StatementText=<optimized out>, TextLength=<optimized out>, ExecDirect=0) at /opt/mariadb-connector-odbc/ma_statement.c:644
 
#8  0x00007f0a136fd91b in SQLPrepare (StatementHandle=0x7f0a6c39d6e0, StatementText=0x7f0a6c0da578 "SELECT * FROM asterisk_ps_endpoints WHERE id = ?", TextLength=-3)
 
    at /opt/mariadb-connector-odbc/odbc_3_api.c:2008
 
#9  0x00007f0a9cbef001 in SQLPrepare () at /lib/x86_64-linux-gnu/libodbc.so.2
 
#10 0x00007f0aa093e3f8 in ast_odbc_prepare (obj=obj@entry=0x7f0a6c2761f0, stmt=0x7f0a6c986d20, sql=0x7f0a6c0da578 "SELECT * FROM asterisk_ps_endpoints WHERE id = ?") at res_odbc.c:475
 
#11 0x00007f0a9ce43e32 in custom_prepare (obj=0x7f0a6c2761f0, data=0x7f0a1b8aa9a0) at res_config_odbc.c:117
 
#12 0x00007f0aa093e95f in ast_odbc_prepare_and_execute (obj=obj@entry=0x7f0a6c2761f0, prepare_cb=prepare_cb@entry=0x7f0a9ce43db0 <custom_prepare>, data=data@entry=0x7f0a1b8aa9a0)
 
    at res_odbc.c:422
 
#13 0x00007f0a9ce46969 in realtime_odbc (database=<optimized out>, table=<optimized out>, fields=<optimized out>) at res_config_odbc.c:219
 
#14 0x00005577e207bfa4 in ast_load_realtime_all_fields (family=family@entry=0x5577e315ac64 "ps_endpoints", fields=fields@entry=0x7f0a6c0f3610) at config.c:3276
 
#15 0x00005577e207c13b in ast_load_realtime_fields (family=family@entry=0x5577e315ac64 "ps_endpoints", fields=fields@entry=0x7f0a6c0f3610) at config.c:3310
 
#16 0x00007f0a4f1e8a74 in sorcery_realtime_retrieve_fields
 
    (sorcery=sorcery@entry=0x5577e3372f00, data=data@entry=0x5577e315ac60, type=type@entry=0x5577e3373a90 "endpoint", fields=fields@entry=0x7f0a6c0f3610) at res_sorcery_realtime.c:170
 
#17 0x00007f0a4f1e8b81 in sorcery_realtime_retrieve_id (sorcery=0x5577e3372f00, data=0x5577e315ac60, type=0x5577e3373a90 "endpoint", id=<optimized out>) at res_sorcery_realtime.c:190
 
#18 0x00005577e201f66e in ast_sorcery_retrieve_by_id (sorcery=0x5577e3372f00, type=type@entry=0x7f0a4c4b5006 "endpoint", id=id@entry=0x7f0a1b8ab690 "54449e8cca784f8daac4@10.0.12.98")
 
    at sorcery.c:1871
 
#19 0x00007f0a4c4b439d in find_endpoint
 
    (rdata=rdata@entry=0x7f0a78002e78, endpoint_name=endpoint_name@entry=0x7f0a1b8ab8e0 "54449e8cca784f8daac4", domain_name=domain_name@entry=0x7f0a1b8ab9e0 "10.0.12.98")
 
    at res_pjsip_endpoint_identifier_user.c:95
 
#20 0x00007f0a4c4b4788 in username_identify (rdata=0x7f0a78002e78) at res_pjsip_endpoint_identifier_user.c:150
 
#21 0x00007f0a4d3c6c72 in ast_sip_identify_endpoint (rdata=rdata@entry=0x7f0a78002e78) at res_pjsip.c:3114
 
#22 0x00007f0a4d3e0758 in endpoint_lookup (rdata=0x7f0a78002e78) at res_pjsip/pjsip_distributor.c:741
 
#23 0x00007f0aa07c8e17 in pjsip_endpt_process_rx_data (endpt=0x5577e31656e8, rdata=rdata@entry=0x7f0a78002e78, p=p@entry=0x7f0a4d40e000 <param>, p_handled=p_handled@entry=0x7f0a1b8abc14)
 
    at ../src/pjsip/sip_endpoint.c:930
 
#24 0x00007f0a4d3deb04 in distribute (data=0x7f0a78002e78) at res_pjsip/pjsip_distributor.c:955
 
#25 0x00005577e203e1a8 in ast_taskprocessor_execute (tps=tps@entry=0x5577e83cb380) at taskprocessor.c:1237
 
#26 0x00005577e2048640 in execute_tasks (data=0x5577e83cb380) at threadpool.c:1356
 
#27 0x00005577e203e1a8 in ast_taskprocessor_execute (tps=0x5577e31620f0) at taskprocessor.c:1237
 
#28 0x00005577e2047e24 in threadpool_execute (pool=0x5577e3161cf0) at threadpool.c:367
 
#29 0x00005577e2047e24 in worker_active (worker=0x7f0a28014f20) at threadpool.c:1137
 
#30 0x00005577e2047e24 in worker_start (arg=arg@entry=0x7f0a28014f20) at threadpool.c:1056
 
#31 0x00005577e204feff in dummy_start (data=<optimized out>) at utils.c:1299
 
#32 0x00007f0a9ff77fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
 
#33 0x00007f0a9fcd24cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95



 Comments   
Comment by Lawrin Novitsky [ 2021-09-06 ]

Interesting. It crashes in malloc. Thus probably won't be easy.
Did it begin with this commit you said you had built with? i.e. before this commit everything was good? Or can you tell me with which commit did that crash first appeared?
Also, I need something to be able to re-create the problem. Would it be possible to get asterisk_ps_endpoints table structure and maybe some sample data ? Not sure if that will be enough, but need to start with something.
Thanks for the report!

Comment by Damjan Jovanovic [ 2021-09-28 ]

The crashes didn't stop with ODBC disabled and it eventually turned out to be a memory corruption issue stemming from another library. In the stack trace reported here, malloc() probably crashed due to heap corruption. With that fixed, MariaDB's ODBC driver worked perfectly during extensive further testing.

Please close this bug as invalid. Sorry to have bothered you for nothing.

Generated at Thu Feb 08 03:27:59 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.