[CONC-593] Periodic SIGABORT in MariaDB ANSI C API Created: 2022-05-20  Updated: 2022-05-28  Resolved: 2022-05-28

Status: Closed
Project: MariaDB Connector/C
Component/s: Other
Affects Version/s: 3.1.17
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Larry Adams Assignee: Unassigned
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

CentOS8.4


 Description   

We are periodically, maybe once a week receiving a sigabort from one of our binaries. The backtrack looks to be deep in the bowels of the API. Wondering if there is a way or method to mitigate this issue. Backtrace is below.

<snip>
 
Program terminated with signal SIGABRT, Aborted.
 
#0  0x00007f8054fdb37f in raise () from /lib64/libc.so.6
 
[Current thread is 1 (Thread 0x7f801cc31700 (LWP 2245832))]
 
Missing separate debuginfos, use: yum debuginfo-install MariaDB-shared-10.5.15-1.el8.x86_64 glibc-2.28-151.el8.x86_64 libgcc-8.4.1-1.el8.x86_64 net-snmp-libs-5.8-20.el8.x86_64 openssl-libs-1.1.1g-15.el8_3.x86_64 zlib-1.2.11-17.el8.x86_64
 
(gdb) bt full
 
#0  0x00007f8054fdb37f in raise () from /lib64/libc.so.6
 
No symbol table info available.
 
#1  0x00007f8054fc5e7e in abort () from /lib64/libc.so.6
 
No symbol table info available.
 
#2  0x00007f805501e4e7 in __libc_message () from /lib64/libc.so.6
 
No symbol table info available.
 
#3  0x00007f80550255ec in malloc_printerr () from /lib64/libc.so.6
 
No symbol table info available.
 
#4  0x00007f805502739c in _int_free () from /lib64/libc.so.6
 
No symbol table info available.
 
#5  0x00007f80550294d5 in _int_realloc () from /lib64/libc.so.6
 
No symbol table info available.
 
#6  0x00007f805502a67b in realloc () from /lib64/libc.so.6
 
No symbol table info available.
 
#7  0x00007f80564ba6e3 in ma_real_read () from /lib64/libmariadb.so.3
 
No symbol table info available.
 
#8  0x00007f80564bb27c in ma_net_read () from /lib64/libmariadb.so.3
 
No symbol table info available.
 
#9  0x00007f80564c080d in ma_net_safe_read () from /lib64/libmariadb.so.3
 
No symbol table info available.
 
#10 0x00007f80564c4595 in mthd_my_read_query_result () from /lib64/libmariadb.so.3
 
No symbol table info available.
 
#11 0x00000000004051eb in db_query (mysql=mysql@entry=0x7f801cc0ece0, type=type@entry=0,
 
    query=query@entry=0x7f801cc0bce0 "UPDATE host SET polling_time = 1652553324.859 - 1652553307.272 WHERE id = 8476") at sql.c:157
 
        mysql_res = 0x0
 
        error = <optimized out>
 
        error_count = 0
 
<snip>



 Comments   
Comment by Georg Richter [ 2022-05-25 ]

Issue was created 4 days ago, but 3.1.17 (reported in affected version) was released today?! Also MariaDB-shared-10.5.15 is shipped with 3.2 - could you please check correct version?

Comment by Larry Adams [ 2022-05-26 ]

Okay sorry about that, I may have posted that version in error. The Client MariaDB-* was at 10.5.15.

I had updated the Client (separate server) to 10.5.15 and that's when the crashes/aborts really increased (I had a few previously but not so regular). The Client was previously at 10.5.8 or 10.5.13. I need to check that tomorrow.

When I backed off to the older version, the crashes/aborts dropped a bunch. The Server is still at 10.5.13.

I'll double back tomorrow and report back, but I'm pretty sure the Client was previously at 10.5.8.

Comment by Larry Adams [ 2022-05-26 ]

Okay, here is the deal:

Client API - MariaDB 10.5.13
ODBC API - mariadb-connector-odbc-3.1.12-1.el8.x86_64

Does this clarify?

Comment by Georg Richter [ 2022-05-27 ]

Thanks for clarification.

According to the backtrace there is a heap corruption which could be caused either by Connector/C, ODBC or your application. The backtrace only shows where the crash occurred, but not the reason for.

Can you try to run your application under valgrind with memcheck?

Comment by Larry Adams [ 2022-05-27 ]

I'm getting slow in my old age. It was not my code, and therefore, I never considered valgrid. Yup, messy business. I informed the vendor to clean up their act. Thanks for the advice.

Comment by Larry Adams [ 2022-05-27 ]

Not quite sure how to close, but putting this here as I try to find my way on JIRA in the dark.

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