Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
3.0.10
-
None
-
None
Description
The ma_alloc_root() function can crash with a segmentation fault.
See the following backtrace:
#0 0x00007ffff63147b7 in _int_malloc () from /lib64/libc.so.6
|
#1 0x00007ffff63171ac in malloc () from /lib64/libc.so.6
|
#2 0x00007ffff7bae29d in ma_alloc_root (mem_root=mem_root@entry=0x630880, Size=Size@entry=24) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/ma_alloc.c:90
|
#3 0x00007ffff7ba9443 in mthd_my_read_rows (mysql=0x627b90, mysql_fields=0x0, fields=8) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/mariadb_lib.c:870
|
#4 0x00007ffff7bacc66 in mthd_my_read_query_result (mysql=0x627b90) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/mariadb_lib.c:2153
|
#5 0x00007ffff7bb3fbb in stmt_read_execute_response (stmt=stmt@entry=0x6304a0) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/mariadb_stmt.c:1815
|
#6 0x00007ffff7bb4c04 in mysql_stmt_execute (stmt=0x6304a0) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/mariadb_stmt.c:2017
|
#7 0x0000000000401e1f in testStoreResult (query="CALL testNoCursor()") at cursortest.cpp:59
|
#8 0x00000000004019a7 in main (argc=1, argv=0x7fffffffe5b8) at cursortest.cpp:19
|
And the following full backtrace:
#0 0x00007ffff63147b7 in _int_malloc () from /lib64/libc.so.6
|
No symbol table info available.
|
#1 0x00007ffff63171ac in malloc () from /lib64/libc.so.6
|
No symbol table info available.
|
#2 0x00007ffff7bae29d in ma_alloc_root (mem_root=mem_root@entry=0x630880, Size=Size@entry=24) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/ma_alloc.c:90
|
get_size = 8168
|
point = <optimized out>
|
next = 0x0
|
prev = 0x630880
|
#3 0x00007ffff7ba9443 in mthd_my_read_rows (mysql=0x627b90, mysql_fields=0x0, fields=8) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/mariadb_lib.c:870
|
field = <optimized out>
|
pkt_len = 63
|
len = <optimized out>
|
cp = 0x62e3b0 "\003def\003db1\vtest_table1\vtest_table1\btest_int\btest_int\f?"
|
to = <optimized out>
|
end_to = <optimized out>
|
result = 0x630870
|
prev_ptr = 0x630870
|
cur = <optimized out>
|
net = 0x627b90
|
#4 0x00007ffff7bacc66 in mthd_my_read_query_result (mysql=0x627b90) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/mariadb_lib.c:2153
|
pos = 0x62e3b2 "ef\003db1\vtest_table1\vtest_table1\btest_int\btest_int\f?"
|
field_count = 1
|
fields = <optimized out>
|
length = <optimized out>
|
#5 0x00007ffff7bb3fbb in stmt_read_execute_response (stmt=stmt@entry=0x6304a0) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/mariadb_stmt.c:1815
|
mysql = 0x627b90
|
ret = <optimized out>
|
#6 0x00007ffff7bb4c04 in mysql_stmt_execute (stmt=0x6304a0) at /usr/src/debug/mariadb-10.3.16-linux-x86_64/shared/src_0/libmariadb/libmariadb/mariadb_stmt.c:2017
|
mysql = 0x627b90
|
request = 0x6329a0 "\001"
|
ret = 0
|
request_len = 9
|
#7 0x0000000000401e1f in testStoreResult (query="CALL testNoCursor()") at cursortest.cpp:59
|
status = 0
|
num_results = 0
|
params = std::vector of length 0, capacity 0
|
set_max_length = 1 '\001'
|
mysql = 0x627b90
|
mysql_stmt = 0x6304a0
|
#8 0x00000000004019a7 in main (argc=1, argv=0x7fffffffe5b8) at cursortest.cpp:19
|
cursorQuery = "CALL testCursor()"
|
noCursorQuery = "CALL testNoCursor()"
|
To reproduce, load the attached schema:
sudo mysql -u root db1 < cursortest.sql
|
And then build the attached program:
g++ -ggdb -c $(mariadb_config --cflags) cursortest.cpp
|
g++ -o cursortest cursortest.o $(mariadb_config --libs)
|
And then run the program.
At that point, you should see the segmentation fault:
$ ./cursortest
|
Query: CALL testCursor()
|
Failed to store result. Error 0 (00000):
|
Result set #1 had 0 rows
|
Received 1 result sets
|
Query: CALL testNoCursor()
|
Segmentation fault
|
See CONC-424 about the empty error.
Attachments
Issue Links
- relates to
-
-
- Closed
-
It looks like some memory was overwritten, since the result bind buffer wasn't initialized properly (e.g. by using malloc instead of calloc)