Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.6
Description
Server crashes when running update statement (which has duplicate key) after setting low thread_stack
# mysqld options required for replay: --thread-stack=1024 |
CREATE TABLE t (a INT KEY); |
INSERT INTO t VALUES (1),(2); |
UPDATE t SET a=2; |
Leads to:
|
10.6.18 567c0973591eb66797bb0f982f312b516f8fe82c (Optimized) |
Core was generated by `/test/MD060324-mariadb-10.6.18-linux-x86_64-opt/bin/mariadbd --no-defaults --ma'.
|
Program terminated with signal SIGSEGV, Segmentation fault.
|
#0 0x00005596c96b5f71 in prepare_record_for_error_message (error=121,
|
table=table@entry=0x15471001a718) at /test/server_opt/sql/sql_update.cc:267
|
[Current thread is 1 (Thread 0x1547580d6700 (LWP 103956))]
|
(gdb) bt
|
#0 0x00005596c96b5f71 in prepare_record_for_error_message (error=121, table=table@entry=0x15471001a718) at /test/server_opt/sql/sql_update.cc:267
|
#1 0x00005596c96b9c34 in mysql_update (thd=thd@entry=0x154710000c58, table_list=<optimized out>, fields=@0x154710005938: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x154710011328, last = 0x154710011328, elements = 1}, <No data fields>}, values=@0x154710005d98: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x154710011338, last = 0x154710011338, elements = 1}, <No data fields>}, conds=<optimized out>, order_num=<optimized out>, order=<optimized out>, limit=18446744073709551615, ignore=<optimized out>, found_return=<optimized out>, updated_return=<optimized out>) at /test/server_opt/sql/sql_update.cc:1148
|
#2 0x00005596c95ea0dc in mysql_execute_command (thd=0x154710000c58, is_called_from_prepared_stmt=<optimized out>) at /test/server_opt/sql/sql_limit.h:94
|
#3 0x00005596c95d8606 in mysql_parse (thd=0x154710000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/server_opt/sql/sql_parse.cc:8143
|
#4 0x00005596c95e50ad in dispatch_command (command=COM_QUERY, thd=0x154710000c58, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/server_opt/sql/sql_class.h:1417
|
#5 0x00005596c95e73fe in do_command (thd=0x154710000c58, blocking=blocking@entry=true) at /test/server_opt/sql/sql_parse.cc:1409
|
#6 0x00005596c9700677 in do_handle_one_connection (connect=<optimized out>, put_in_cache=true) at /test/server_opt/sql/sql_connect.cc:1415
|
#7 0x00005596c97009bd in handle_one_connection (arg=arg@entry=0x5596cc4d00c8) at /test/server_opt/sql/sql_connect.cc:1317
|
#8 0x00005596c9ab581c in pfs_spawn_thread (arg=0x5596cc47d658) at /test/server_opt/storage/perfschema/pfs.cc:2201
|
#9 0x000015475b3bc609 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#10 0x000015475afa8133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
Bug confirmed present in:
MariaDB: 10.6.18 (dbg), 10.6.18 (opt)
Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.4.33 (dbg), 10.4.33 (opt), 10.5.25 (dbg), 10.5.25 (opt), 10.11.7 (dbg), 10.11.7 (opt), 11.0.6 (dbg), 11.0.6 (opt), 11.1.4 (dbg), 11.1.4 (opt), 11.2.4 (dbg), 11.2.4 (opt), 11.3.2 (dbg), 11.3.2 (opt), 11.4.2 (dbg), 11.4.2 (opt), 11.5.0 (opt), 11.5.0 (dbg)
Attachments
Issue Links
- is caused by
-
-
- Closed
-
Activity
The usage of --thread-stack=1024 is only for testing and can cause crashes 'anywhere'.
That said, there was an old bug in prepare_record_for_error_message() that before allocated 4x more memory than was needed.
After my bitmap changes the extra memory requirement is 8x times more.
The fix changes the stack requirements for the function from 4096 bytes to 512 bytes (which is what is needed to have a bitmap for up to 4096 fields).
Fixed too big stack allocation in prepare_record_for_error_message()
This failed before the bug fix for the stack:
Start mariadbd --thread_stack=150K
create table t2 (a int primary key);
insert into t2 values (1),(2);
update t2 set a=2 where a=1;
This will crash in prepare_record_for_error_message() because it is out of stack
The crash occurs after this commit
commit b5d65fc105b6efa07cbbafcf053f6ce46f02dbc0 (HEAD)Author: Monty <monty@mariadb.org>Date: Sun Feb 18 17:30:01 2024 +0200Optimize performance of my_bitmapMDEV-33502 Slowdown when running nested statement with many partitionsThis change was triggered to help some MariaDB users with close to10000 bits in their bitmaps.[..]