Sergei Golubchik added a comment - 2025-03-12 08:58 I've run this for 15 minutes, no crash. May be it was fixed meanwhile

Juan Ferrer Toribio added a comment - 2025-03-24 09:45 - edited It is still there, at least in 10.11.6. A possible workaround would be. DELIMITER $$ CREATE OR REPLACE DEFINER=`root`@`localhost` TRIGGER `bar_bi` BEFORE INSERT ON `bar` FOR EACH ROW BEGIN SET NEW.x = NEXTVAL(foo); END $$ DELIMITER ; Report for 10.11.6 It doesn't happen in all INSERTs, it seems only when there is high concurrency. We have had it running for 2 weeks in our test environment and the crash only happened when moving to production. CREATE SEQUENCE IF NOT EXISTS vn.buyLot; ALTER TABLE vn.sale ADD COLUMN IF NOT EXISTS lotFk INT UNSIGNED NOT NULL DEFAULT NEXTVAL(vn.buyLot) AFTER id; ALTER TABLE vn.buy ADD COLUMN IF NOT EXISTS lotFk INT UNSIGNED NOT NULL DEFAULT NEXTVAL(vn.buyLot) AFTER id; CREATE TABLE `sale` ( `id` int ( 11 ) NOT NULL AUTO_INCREMENT, `lotFk` int ( 10 ) unsigned DEFAULT NULL, `itemFk` int ( 11 ) NOT NULL, `ticketFk` int ( 11 ) NOT NULL, `concept` varchar( 50 ) DEFAULT NULL, `quantity` decimal( 10 , 2 ) NOT NULL DEFAULT 0.00 , `originalQuantity` decimal( 10 , 2 ) NOT NULL DEFAULT 0.00 COMMENT 'Se utiliza para notificar a través de rocket los cambios de quantity' , `price` decimal( 10 , 2 ) NOT NULL DEFAULT 0.00 , `discount` tinyint( 2 ) unsigned NOT NULL DEFAULT 0 , `priceFixed` decimal( 10 , 2 ) NOT NULL DEFAULT 0.00 , `reserved` tinyint( 1 ) NOT NULL DEFAULT 0 , `isPicked` tinyint( 1 ) NOT NULL DEFAULT 0 , `isPriceFixed` tinyint( 1 ) NOT NULL DEFAULT 0 , `created` timestamp NOT NULL DEFAULT current_timestamp(), `isAdded` tinyint( 1 ) NOT NULL DEFAULT 0 , `total` decimal( 10 , 2 ) GENERATED ALWAYS AS (`price` * `quantity` * ( 100 - `discount`) / 100 ) VIRTUAL, `editorFk` int ( 10 ) unsigned DEFAULT NULL, `problem` set( 'hasItemShortage' , 'hasComponentLack' , 'hasItemDelay' , 'hasRounding' , 'hasItemLost' ) NOT NULL DEFAULT '' , PRIMARY KEY (`id`), KEY `Id_Ticket` (`ticketFk`), KEY `itemFk_ticketFk` (`itemFk`,`ticketFk`), KEY `sale_fk_editor` (`editorFk`), KEY `sale_created_IDX` (`created`) USING BTREE, CONSTRAINT `movement_ticket_id` FOREIGN KEY (`ticketFk`) REFERENCES `ticket` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `sale_fk_editor` FOREIGN KEY (`editorFk`) REFERENCES `account`.`user` (`id`), CONSTRAINT `sale_ibfk_1` FOREIGN KEY (`itemFk`) REFERENCES `item` (`id`) ON UPDATE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT= 52638307 DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_unicode_ci Crash log 250311 10:40:50 [ERROR] mysqld got signal 11 ; Sorry, we probably made a mistake, and this is a bug.   Your assistance in bug reporting will enable us to fix this for the next release. To report this bug, see https://mariadb.com/kb/en/reporting-bugs   We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail.   Server version: 10.11.6-MariaDB-1:10.11.6+maria~deb12-log source revision: fecd78b83785d5ae96f2c6ff340375be803cd299 key_buffer_size=262144 read_buffer_size=1048576 max_used_connections=525 max_threads=1002 thread_count=322 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 5157218 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.   Thread pointer: 0x7fdc94000c68 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7fdd3a33cc78 thread_stack 0x80000 Printing to addr2line failed /usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x558e668b0fbe] /usr/sbin/mariadbd(handle_fatal_signal+0x2b3)[0x558e66394173] /lib/x86_64-linux-gnu/libc.so.6(+0x3c050)[0x7feda5c5b050] /usr/sbin/mariadbd(_ZN17Item_func_nextval7val_intEv+0x1f3)[0x558e66403783] /usr/sbin/mariadbd(_ZN4Item17save_int_in_fieldEP5Fieldb+0x1f)[0x558e663bb2ef] /usr/sbin/mariadbd(_ZN4Item13save_in_fieldEP5Fieldb+0x35)[0x558e663abc05] /usr/sbin/mariadbd(_ZN5TABLE21update_default_fieldsEb+0xac)[0x558e6623d1ac] /usr/sbin/mariadbd(_Z11fill_recordP3THDP5TABLER4ListI4ItemES6_bb+0x2db)[0x558e660d59cb] /usr/sbin/mariadbd(_Z36fill_record_n_invoke_before_triggersP3THDP5TABLER4ListI4ItemES6_b14trg_event_type+0x3a)[0x558e660d5d1a] /usr/sbin/mariadbd(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesbP13select_result+0xf07)[0x558e6610b717] /usr/sbin/mariadbd(_Z21mysql_execute_commandP3THDb+0x17b5)[0x558e6613e205] /usr/sbin/mariadbd(_ZN13sp_instr_stmt9exec_coreEP3THDPj+0x17)[0x558e660883b7] /usr/sbin/mariadbd(_ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr+0x15c)[0x558e6609170c] /usr/sbin/mariadbd(_ZN13sp_instr_stmt7executeEP3THDPj+0x5a6)[0x558e66092116] /usr/sbin/mariadbd(_ZN7sp_head7executeEP3THDb+0x97b)[0x558e6608bdfb] /usr/sbin/mariadbd(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x5af)[0x558e6608d95f] /usr/sbin/mariadbd(+0x80c927)[0x558e66131927] /usr/sbin/mariadbd(_ZN12Sql_cmd_call7executeEP3THD+0x15e)[0x558e6613662e] /usr/sbin/mariadbd(_Z21mysql_execute_commandP3THDb+0xf86)[0x558e6613d9d6] /usr/sbin/mariadbd(_ZN13sp_instr_stmt9exec_coreEP3THDPj+0x17)[0x558e660883b7] /usr/sbin/mariadbd(_ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr+0x15c)[0x558e6609170c] /usr/sbin/mariadbd(_ZN13sp_instr_stmt7executeEP3THDPj+0x5a6)[0x558e66092116] /usr/sbin/mariadbd(_ZN7sp_head7executeEP3THDb+0x97b)[0x558e6608bdfb] /usr/sbin/mariadbd(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x5af)[0x558e6608d95f] /usr/sbin/mariadbd(+0x80c927)[0x558e66131927] /usr/sbin/mariadbd(_ZN12Sql_cmd_call7executeEP3THD+0x15e)[0x558e6613662e] /usr/sbin/mariadbd(_Z21mysql_execute_commandP3THDb+0xf86)[0x558e6613d9d6] /usr/sbin/mariadbd(_ZN13sp_instr_stmt9exec_coreEP3THDPj+0x17)[0x558e660883b7] /usr/sbin/mariadbd(_ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr+0x15c)[0x558e6609170c] /usr/sbin/mariadbd(_ZN13sp_instr_stmt7executeEP3THDPj+0x5a6)[0x558e66092116] /usr/sbin/mariadbd(_ZN7sp_head7executeEP3THDb+0x97b)[0x558e6608bdfb] /usr/sbin/mariadbd(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x5af)[0x558e6608d95f] /usr/sbin/mariadbd(+0x80c927)[0x558e66131927] /usr/sbin/mariadbd(_ZN12Sql_cmd_call7executeEP3THD+0x15e)[0x558e6613662e] /usr/sbin/mariadbd(_Z21mysql_execute_commandP3THDb+0xf86)[0x558e6613d9d6] /usr/sbin/mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x1c6)[0x558e661429d6] /usr/sbin/mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x1a45)[0x558e661456d5] /usr/sbin/mariadbd(_Z10do_commandP3THDb+0x134)[0x558e66146ed4] /usr/sbin/mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x3b7)[0x558e6626aa37] /usr/sbin/mariadbd(handle_one_connection+0x5d)[0x558e6626adad] /usr/sbin/mariadbd(+0xc8ec80)[0x558e665b3c80] /lib/x86_64-linux-gnu/libc.so.6(+0x891c4)[0x7feda5ca81c4] /lib/x86_64-linux-gnu/libc.so.6(+0x10985c)[0x7feda5d2885c]   Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fdc944d7cf8): INSERT INTO vn.sale SET itemFk = NAME_CONST('vItemFk',61950), ticketFk = NAME_CONST('vTicketFk',10969461), concept = NAME_CONST('vConcept',_utf8mb3'Lino Verde' COLLATE 'utf8mb3_unicode_ci'), quantity = NAME_CONST('vAmount',1), price = NAME_CONST('vPrice',5.57), priceFixed = NAME_CONST('vPriceFixed',5.15), isPriceFixed = TRUE   Connection ID (thread ID): 227161 Status: NOT_KILLED   Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off,hash_join_cardinality=off,cset_narrowing=off   The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains information that should help you find out what is causing the crash. Writing a core file... Working directory at /mnt/mysqldata/mysql Resource Limits: Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 648357 648357 processes Max open files 600000 600000 files Max locked memory 2097152 2097152 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 648357 648357 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Core pattern: core   Kernel version: Linux version 6.1.0-31-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07)

Sergei Golubchik added a comment - 2025-03-24 10:00 Right, but the latest version is 10.11.11. Does it repeat there?

Juan Ferrer Toribio added a comment - 2025-03-24 10:12 - edited Sorry, I don't know. We cannot go to 10.11.11 because we were affected by MDEV-36026 . Maybe our case is also MDEV-31854 but if you see the crash logs it seems to be caused by an INSERT statement.

Sergei Golubchik added a comment - 2025-03-24 13:03 Sure, and sorry for MDEV-36026 regression. If you'll ever upgrade to 10.11.12 or a later version and see this bug still reproducible, drop a line here and we'll reopen.