Debian 12

it has nothing to do with the stored procedure. Even if I try to prepare and execute the statement directly, with no prepared statement, it crashes. So this code makes mariadb crash:
SET @INJahr:=2022;
SET @INHaus:=24;
CALL setparam(0,0,@INJahr);
SET @steuernr:=(SELECT SteuerNr FROM Haus WHERE Id=@INHaus);
SET @mult:=(SELECT COUNT(Id) FROM Haus WHERE SteuerNr=@steuernr);
SET @sqldyn:=(select group_concat(CONCAT(
"
sum(if(h.Id=",Id,",j.Ein,0)) AS '",
NAME,
"|Einnahmen',
sum(if(h.Id=",Id,",j.Aus,0)) AS '",
NAME,
"|Ausgaben'"))
FROM Haus WHERE SteuerNr=@steuernr ORDER BY Id);

SET @SQL:=CONCAT("select
j.Konto,
k.Bezeichnung AS 'Bezeichnung',"
,@sqldyn,
if(@mult>1,",
sum(j.Ein) AS 'Summe|Einnahmen',
sum(j.Aus) AS 'Summe|Ausgaben'",""),"
FROM JournalUst j
LEFT JOIN Konten k ON(j.Konto = k.Nummer AND j.Haus = k.Haus)
LEFT JOIN Parameter p ON(p.connection = '",
CONNECTION_ID(),"')
LEFT JOIN Haus h ON(h.Id = j.Haus)
WHERE k.istumzubuchen <> 0 AND
(k.AbsetzungJahre = 0 OR k.AbsetzungJahre IS NULL) AND
j.Datum LIKE CONCAT(`p`.`Jahr`,'%') AND
j.Text NOT LIKE '%bertrag' AND
j.Text NOT LIKE 'Umbuchung%' AND
h.SteuerNr='",
@steuernr,"'
GROUP BY h.SteuerNr,j.Konto
ORDER BY h.SteuerNr,j.Konto ");

PREPARE stmt FROM @SQL;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;

but this query, the resulting @sql from the above, works:

select
j.Konto,
k.Bezeichnung AS 'Bezeichnung',
sum(if(h.Id=13,j.Ein,0)) AS 'Eichenstr. 2c|Einnahmen',
sum(if(h.Id=13,j.Aus,0)) AS 'Eichenstr. 2c|Ausgaben',
sum(if(h.Id=15,j.Ein,0)) AS '1170 Jörgerstr.3-5|Einnahmen',
sum(if(h.Id=15,j.Aus,0)) AS '1170 Jörgerstr.3-5|Ausgaben',
sum(if(h.Id=21,j.Ein,0)) AS 'Brückeng.10-12|Einnahmen',
sum(if(h.Id=21,j.Aus,0)) AS 'Brückeng.10-12|Ausgaben',
sum(if(h.Id=22,j.Ein,0)) AS 'Mayerhofg.9|Einnahmen',
sum(if(h.Id=22,j.Aus,0)) AS 'Mayerhofg.9|Ausgaben',
sum(if(h.Id=23,j.Ein,0)) AS 'Troststr.61|Einnahmen',
sum(if(h.Id=23,j.Aus,0)) AS 'Troststr.61|Ausgaben',
sum(if(h.Id=24,j.Ein,0)) AS 'Ottakringerstr.69|Einnahmen',
sum(if(h.Id=24,j.Aus,0)) AS 'Ottakringerstr.69|Ausgaben',
sum(if(h.Id=32,j.Ein,0)) AS 'Lerchenfelderstr.49|Einnahmen',
sum(if(h.Id=32,j.Aus,0)) AS 'Lerchenfelderstr.49|Ausgaben',
sum(j.Ein) AS 'Summe|Einnahmen',
sum(j.Aus) AS 'Summe|Ausgaben'
FROM JournalUst j
LEFT JOIN Konten k ON(j.Konto = k.Nummer AND j.Haus = k.Haus)
LEFT JOIN Parameter p ON(p.connection = '30')
LEFT JOIN Haus h ON(h.Id = j.Haus)
WHERE k.istumzubuchen <> 0 AND
(k.AbsetzungJahre = 0 OR k.AbsetzungJahre IS NULL) AND
j.Datum LIKE CONCAT(`p`.`Jahr`,'%') AND
j.Text NOT LIKE '%bertrag' AND
j.Text NOT LIKE 'Umbuchung%' AND
h.SteuerNr='078430881'
GROUP BY h.SteuerNr,j.Konto
ORDER BY h.SteuerNr,j.Konto

Es sieht so aus, als ob der eingebaute Stacktrace oberhalb von st_select_lex::update_used_tables() nicht richtig ist. Können Sie bitte einen besseren Stacktrace mit Hilfe eines Debuggers erstellen, wie es https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ erklärt?

hope this helps:
Mai 31 14:31:20 lampe mariadbd[578]: 230531 14:31:20 [ERROR] mysqld got signal 11 ;
Mai 31 14:31:20 lampe mariadbd[578]: This could be because you hit a bug. It is also possible that this binary
Mai 31 14:31:20 lampe mariadbd[578]: or one of the libraries it was linked against is corrupt, improperly built,
Mai 31 14:31:20 lampe mariadbd[578]: or misconfigured. This error can also be caused by malfunctioning hardware.
Mai 31 14:31:20 lampe mariadbd[578]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
Mai 31 14:31:20 lampe mariadbd[578]: We will try our best to scrape up some info that will hopefully help
Mai 31 14:31:20 lampe mariadbd[578]: diagnose the problem, but since we have already crashed,
Mai 31 14:31:20 lampe mariadbd[578]: something is definitely wrong and this may fail.
Mai 31 14:31:20 lampe mariadbd[578]: Server version: 10.5.19-MariaDB-0+deb11u2 source revision: f8a85af8ca1c937b8d4f847477bd282f80251cde
Mai 31 14:31:20 lampe mariadbd[578]: key_buffer_size=134217728
Mai 31 14:31:20 lampe mariadbd[578]: read_buffer_size=131072
Mai 31 14:31:20 lampe mariadbd[578]: max_used_connections=1
Mai 31 14:31:20 lampe mariadbd[578]: max_threads=153
Mai 31 14:31:20 lampe mariadbd[578]: thread_count=1
Mai 31 14:31:20 lampe mariadbd[578]: It is possible that mysqld could use up to
Mai 31 14:31:20 lampe mariadbd[578]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467880 K bytes of memory
Mai 31 14:31:20 lampe mariadbd[578]: Hope that's ok; if not, decrease some variables in the equation.
Mai 31 14:31:20 lampe mariadbd[578]: Thread pointer: 0x7fd1f8000c58
Mai 31 14:31:20 lampe mariadbd[578]: Attempting backtrace. You can use the following information to find out
Mai 31 14:31:20 lampe mariadbd[578]: where mysqld died. If you see no messages after this, something went
Mai 31 14:31:20 lampe mariadbd[578]: terribly wrong...
Mai 31 14:31:20 lampe mariadbd[578]: stack_bottom = 0x7fd22d1bdd78 thread_stack 0x49000
Mai 31 14:31:21 lampe mariadbd[578]: /usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x561e0c01816e]
Mai 31 14:31:21 lampe mariadbd[578]: /usr/sbin/mariadbd(handle_fatal_signal+0x485)[0x561e0bb10f45]
Mai 31 14:31:21 lampe mariadbd[578]: ??:0(__restore_rt)[0x7fd245216140]
Mai 31 14:31:22 lampe mariadbd[578]: /usr/sbin/mariadbd(_ZNK10Item_field11used_tablesEv+0x7)[0x561e0bb39fb7]
Mai 31 14:31:22 lampe mariadbd[578]: /usr/sbin/mariadbd(_ZNK20Item_direct_view_ref11used_tablesEv+0x6b)[0x561e0bb3a49b]
Mai 31 14:31:23 lampe mariadbd[578]: sql/item.cc:3477(Item_field::used_tables() const)[0x561e0b8cc802]
Mai 31 14:31:23 lampe mariadbd[578]: sql/item.cc:10756(Item_direct_view_ref::used_tables() const)[0x561e0b8cc7f5]
Mai 31 14:31:23 lampe mariadbd[578]: sql/item.h:5175(Used_tables_and_const_cache::used_tables_and_const_cache_join(Item const*))[0x561e0b8ef4ad]
Mai 31 14:31:23 lampe mariadbd[578]: sql/item.h:5175(Used_tables_and_const_cache::used_tables_and_const_cache_join(Item const*))[0x561e0b977a18]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_lex.cc:5298(st_select_lex::update_used_tables())[0x561e0b97b300]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_select.cc:1901(JOIN::optimize_inner())[0x561e0b9c55b0]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_select.cc:1697(JOIN::optimize())[0x561e0b8d3078]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_union.cc:2137(st_select_lex_unit::optimize())[0x561e0b8d2875]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_derived.cc:1055(mysql_derived_optimize(THD*, LEX*, TABLE_LIST*))[0x561e0b97872f]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_derived.cc:200(mysql_handle_single_derived(LEX*, TABLE_LIST*, unsigned int))[0x561e0b97b300]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_select.cc:1697(JOIN::optimize())[0x561e0b9c55b0]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_union.cc:2137(st_select_lex_unit::optimize())[0x561e0b8d3078]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_derived.cc:1055(mysql_derived_optimize(THD*, LEX*, TABLE_LIST*))[0x561e0b8d2875]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_derived.cc:200(mysql_handle_single_derived(LEX*, TABLE_LIST*, unsigned int))[0x561e0b97872f]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_select.cc:2155(JOIN::optimize_inner())[0x561e0b97b300]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_select.cc:1697(JOIN::optimize())[0x561e0b97b3d3]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_select.cc:4823(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_u>
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_select.cc:445(handle_select(THD*, LEX*, select_result*, unsigned long))[0x561e0b90bd91]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_parse.cc:6319(execute_sqlcom_select(THD*, TABLE_LIST*))[0x561e0b918abb]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_parse.cc:4008(mysql_execute_command(THD*))[0x561e0b92d645]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_prepare.cc:5077(Prepared_statement::execute(String*, bool))[0x561e0b92d78d]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_prepare.cc:4521(Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*))[0x561e0b92dae6]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_class.h:1537(Item_change_list_savepoint::rollback(Item_change_list*))[0x561e0b917c10]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_parse.cc:4024(mysql_execute_command(THD*))[0x561e0b919f6b]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_parse.cc:8108(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x561e0b91bd2d]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_parse.cc:1894(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x561e0b91dc70]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_parse.cc:1375(do_command(THD*))[0x561e0ba116c2]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_connect.cc:1416(do_handle_one_connection(CONNECT*, bool))[0x561e0ba1193d]
Mai 31 14:31:23 lampe mariadbd[578]: sql/sql_connect.cc:1318(handle_one_connection)[0x561e0bd5175b]
Mai 31 14:31:23 lampe mariadbd[578]: ??:0(start_thread)[0x7fd24520aea7]
Mai 31 14:31:23 lampe mariadbd[578]: ??:0(clone)[0x7fd244e11a2f]
Mai 31 14:31:23 lampe mariadbd[578]: Trying to get some variables.
Mai 31 14:31:23 lampe mariadbd[578]: Some pointers may be invalid and cause the dump to abort.
Mai 31 14:31:23 lampe mariadbd[578]: Query (0x7fd1f82b4040): select
Mai 31 14:31:23 lampe mariadbd[578]: j.Konto,
Mai 31 14:31:23 lampe mariadbd[578]: k.Bezeichnung AS 'Bezeichnung',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=13,j.Ein,0)) AS 'Eichenstr. 2c|Einnahmen',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=13,j.Aus,0)) AS 'Eichenstr. 2c|Ausgaben',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=15,j.Ein,0)) AS '1170 Jörgerstr.3-5|Einnahmen',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=15,j.Aus,0)) AS '1170 Jörgerstr.3-5|Ausgaben',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=21,j.Ein,0)) AS 'Brückeng.10-12|Einnahmen',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=21,j.Aus,0)) AS 'Brückeng.10-12|Ausgaben',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=22,j.Ein,0)) AS 'Mayerhofg.9|Einnahmen',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=22,j.Aus,0)) AS 'Mayerhofg.9|Ausgaben',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=23,j.Ein,0)) AS 'Troststr.61|Einnahmen',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=23,j.Aus,0)) AS 'Troststr.61|Ausgaben',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=24,j.Ein,0)) AS 'Ottakringerstr.69|Einnahmen',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=24,j.Aus,0)) AS 'Ottakringerstr.69|Ausgaben',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=32,j.Ein,0)) AS 'Lerchenfelderstr.49|Einnahmen',
Mai 31 14:31:23 lampe mariadbd[578]: sum(if(h.Id=32,j.Aus,0)) AS 'Lerchenfelderstr.49|Ausgaben',
Mai 31 14:31:23 lampe mariadbd[578]: sum(j.Ein) AS 'Summe|Einnahmen',
Mai 31 14:31:23 lampe mariadbd[578]: sum(j.Aus) AS 'Summe|Ausgaben'
Mai 31 14:31:23 lampe mariadbd[578]: FROM JournalUst j
Mai 31 14:31:23 lampe mariadbd[578]: LEFT JOIN Konten k ON(j.Konto = k.Nummer AND j.Haus = k.Haus)
Mai 31 14:31:23 lampe mariadbd[578]: LEFT JOIN Parameter p ON(p.connection = '30')
Mai 31 14:31:23 lampe mariadbd[578]: LEFT JOIN Haus h ON(h.Id = j.Haus)
Mai 31 14:31:23 lampe mariadbd[578]: WHERE k.istumzubuchen <> 0 AND
Mai 31 14:31:23 lampe mariadbd[578]: (k.AbsetzungJahre = 0 OR k.AbsetzungJahre IS NULL) AND
Mai 31 14:31:23 lampe mariadbd[578]: j.Datum LIKE CONCAT(`p`.`Jahr`,'%') AND
Mai 31 14:31:23 lampe mariadbd[578]: j.Text NOT LIKE '%bertrag' AND
Mai 31 14:31:23 lampe mariadbd[578]: j.Text NOT LIKE 'Umbuchung%' AND
Mai 31 14:31:23 lampe mariadbd[578]: h.SteuerNr='078430881'
Mai 31 14:31:23 lampe mariadbd[578]: GROUP BY h.SteuerNr,j.Konto
Mai 31 14:31:23 lampe mariadbd[578]: ORDER BY h.SteuerNr,j.Konto
Mai 31 14:31:23 lampe mariadbd[578]: Connection ID (thread ID): 30
Mai 31 14:31:23 lampe mariadbd[578]: Status: NOT_KILLED
Mai 31 14:31:23 lampe mariadbd[578]: 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_co>
Mai 31 14:31:23 lampe mariadbd[578]: The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
Mai 31 14:31:23 lampe mariadbd[578]: information that should help you find out what is causing the crash.
Mai 31 14:31:23 lampe mariadbd[578]: Writing a core file...
Mai 31 14:31:23 lampe mariadbd[578]: Writing a core file...
Mai 31 14:31:23 lampe mariadbd[578]: Working directory at /var/lib/mysql
Mai 31 14:31:23 lampe mariadbd[578]: Resource Limits:
Mai 31 14:31:23 lampe mariadbd[578]: Limit Soft Limit Hard Limit Units
Mai 31 14:31:23 lampe mariadbd[578]: Max cpu time unlimited unlimited seconds
Mai 31 14:31:23 lampe mariadbd[578]: Max file size unlimited unlimited bytes
Mai 31 14:31:23 lampe mariadbd[578]: Max data size unlimited unlimited bytes
Mai 31 14:31:23 lampe mariadbd[578]: Max stack size 8388608 unlimited bytes
Mai 31 14:31:23 lampe mariadbd[578]: Max core file size 0 unlimited bytes
Mai 31 14:31:23 lampe mariadbd[578]: Max resident set unlimited unlimited bytes
Mai 31 14:31:23 lampe mariadbd[578]: Max processes 7743 7743 processes
Mai 31 14:31:23 lampe mariadbd[578]: Max open files 32768 32768 files
Mai 31 14:31:23 lampe mariadbd[578]: Max locked memory 65536 65536 bytes
Mai 31 14:31:23 lampe mariadbd[578]: Max address space unlimited unlimited bytes
Mai 31 14:31:23 lampe mariadbd[578]: Max file locks unlimited unlimited locks
Mai 31 14:31:23 lampe mariadbd[578]: Max pending signals 7743 7743 signals
Mai 31 14:31:23 lampe mariadbd[578]: Max msgqueue size 819200 819200 bytes
Mai 31 14:31:23 lampe mariadbd[578]: Max nice priority 0 0
Mai 31 14:31:23 lampe mariadbd[578]: Max realtime priority 0 0
Mai 31 14:31:23 lampe mariadbd[578]: Max realtime timeout unlimited unlimited us
Mai 31 14:31:23 lampe mariadbd[578]: Core pattern: core
Mai 31 14:31:23 lampe mariadbd[578]: Kernel version: Linux version 5.10.0-23-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.1>
Mai 31 14:31:23 lampe systemd[1]: mariadb.service: Main process exited, code=killed, status=11/SEGV
Mai 31 14:31:23 lampe systemd[1]: mariadb.service: Failed with result 'signal'.
Mai 31 14:31:23 lampe systemd[1]: mariadb.service: Consumed 3.379s CPU time.

I see that it crashes 7 bytes after the start of Item_field::used_tables() const. The code is:

table_map Item_field::used_tables() const

{

  if (field->table->const_table)

    return 0;					// const item

  return (get_depended_from() ? OUTER_REF_TABLE_BIT : field->table->map);

}

I would guess that field or field->table is a null pointer.

Thank you, I am getting closer. There is a (sub-)view, which consists of a select with 3 Unions. A column I called "Text", which was maybe not a perfect decision, is a Text field in 2 of the selects and a concat-ed string in the third, like this:
select ... j.Text ... from abc j where .... union
select ... j.Text ... from bcd j where ... union
select GROUP_CONCAT(CONCAT(`j`.`Ust`,'% aus ',`j`.`Ein`) SEPARATOR ' und ')) AS `Text` from cde j where ....

It crashes when I select this view and include into the where-clause:
...j.Text NOT LIKE '%bertrag' AND
j.Text NOT LIKE 'Umbuchung%' ...

Everythings works fine, if I leave this part out. It also works witch only the third select (group_concat....), so I think the crash happens, when I try to search in the average Text-column AND the concat-ed simultaniously.
Everything is also fine, when I run the query without prepare ... execute.

so finally I found what causes the crash: I had a view with a column

concat(..,CAST(`z`.`Ust` AS CHAR CHARSET utf8mb4),..) as Text

another view selects this view twice with a union. No problem, unless this view is called in a prepared statement.

I just removed the cast() (since I cant remember why I put it there) and everything is fine, no crash.

My problem is solved, if you want to investigate anything further, let me know.

georgg, thank you. The database is not supposed to crash on any input, even if it was invalid input.

Would it be possible for you to create a minimal self-contained SQL test case of this? It would start with CREATE and INSERT statements and finally the crashing SELECT. Possibly, the tables could be reduced to a subset of the rows that the WHERE condition would match (and the WHERE conditions could then be omitted from the crashing SELECT). Also, any columns that the crashing query does not depend on might be dropped from the underlying tables and views, and the query would still crash.

CREATE TABLE `Test` (
`Text` TEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci'
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;
ALTER ALGORITHM = UNDEFINED DEFINER=xxxxxx SQL SECURITY DEFINER VIEW `Test_View1` AS select concat(`l`.`Text`,' (Test ',cast('Test' as char charset utf8mb4),'%)') AS `Text` from `Test` `l` ;

ALTER ALGORITHM = UNDEFINED DEFINER=xxxxxx SQL SECURITY DEFINER VIEW `Test_View2` AS select `j`.`Text` AS `Text` from `Test_View1` `j` union select `j`.`Text` AS `Text` from Test_View1` `j` ;

INSERT INTO Test VALUES ("Test");

prepare stmt FROM
'select Text FROM
Test_View2
WHERE TEXT LIKE "%t%"';
execute stmt;
DEALLOCATE PREPARE stmt;

This crashes my server. From now it look loke a coalition-problem.

I can reproduce the crash with the following:

CREATE OR REPLACE TABLE t1 (

Text TEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci'

) COLLATE='utf8_general_ci';

INSERT INTO t1 VALUES ('Test');

CREATE OR REPLACE VIEW v1 AS select concat(l.Text,' (Test ',cast('Test' as char charset utf8mb4),'%)') AS Text from t1 l ;

CREATE OR REPLACE VIEW v2 AS select j.Text AS Text from v1 j union select j.Text AS Text from v1 j;

prepare stmt FROM 'select Text FROM v2 WHERE TEXT LIKE "%t%"';

execute stmt;

DEALLOCATE PREPARE stmt;

#3  0x00005587cb833845 in handle_fatal_signal (sig=11) at /mariadb/10.5/sql/signal_handler.cc:356

#4  <signal handler called>

#5  0x00005587cb752d39 in Item_field::used_tables (this=0x7ff4e4049a90) at /mariadb/10.5/sql/item.cc:3477

#6  0x00005587cb71ebe4 in Used_tables_and_const_cache::used_tables_and_const_cache_join (this=this@entry=0x7ff4e4015050, item=item@entry=0x7ff4e4049a90) at /mariadb/10.5/sql/item.h:5175

The function is trying to dereference field=nullptr.

This report could duplicate something that has already been fixed. The test case does not crash for me on MariaDB Server 10.5.20.

georgg, did upgrading help you? is the server still crashing?

I have not upgraded until yet, but changed my query. I am on Debian 11 and will probably upgrade to 12, what will bring a upgrade to mariadb as well, within the next months.

If upgrade doesn't help, please feel free to comment so that the report gets re-opened.