[debian-mysql] Bug#1128359: libdbd-mysql-perl: FTBFS: Failed 1/77 test programs. 0/412 subtests failed.

Wed Feb 18 19:51:52 GMT 2026

Control: tag -1 - forky
Control: tag -1 + confirmed

On Wed, 18 Feb 2026 19:23:30 +0000, Santiago Vila wrote:

>Package: src:libdbd-mysql-perl
>Version: 4.054-1
>Severity: serious
>Tags: ftbfs forky sid
>
>Dear maintainer:
>
>During a rebuild of all packages in unstable, this package failed to build.
>

>260218 18:09:37 [ERROR] /usr/sbin/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 about how to report
>a bug on https://jira.mariadb.org/.
>
>Please include the information from the server start above, to the end of the
>information below.
>
>Server version: 11.8.6-MariaDB-1 from Debian source revision: 9bfea48ce1214cc4470f6f6f8a4e30352cef84e7
>
>The information page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/
>contains instructions to obtain a better version of the backtrace below.
>Following these instructions will help MariaDB developers provide a fix quicker.
>
>Attempting backtrace. Include this in the bug report.
>(note: Retrieving this information may fail)
>
>Thread pointer: 0x7f01fc000cd8
>stack_bottom = 0x7f0230313000 thread_stack 0x49000
>/usr/sbin/mysqld(my_print_stacktrace+0x32) [0x5651795004f2]
>/usr/sbin/mysqld(handle_fatal_signal+0x1a7) [0x565178f78247]
>/usr/lib/x86_64-linux-gnu/libc.so.6(+0x40a70) [0x7f0247a4aa70]
>
>Connection ID (thread ID): 28
>Status: NOT_KILLED
>Query (0x7f01fc012fd0): SELECT NULL AS PKTABLE_CAT,
>       A.REFERENCED_TABLE_SCHEMA AS PKTABLE_SCHEM,
>       A.REFERENCED_TABLE_NAME AS PKTABLE_NAME,
>       A.REFERENCED_COLUMN_NAME AS PKCOLUMN_NAME,
>       A.TABLE_CATALOG AS FKTABLE_CAT,
>       A.TABLE_SCHEMA AS FKTABLE_SCHEM,
>       A.TABLE_NAME AS FKTABLE_NAME,
>       A.COLUMN_NAME AS FKCOLUMN_NAME,
>       A.ORDINAL_POSITION AS KEY_SEQ,
>       NULL AS UPDATE_RULE,
>       NULL AS DELETE_RULE,
>       A.CONSTRAINT_NAME AS FK_NAME,
>       NULL AS PK_NAME,
>       NULL AS DEFERABILITY,
>       NULL AS UNIQUE_OR_PRIMARY
>  FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE A,
>       INFORMATION_SCHEMA.TABLE_CONSTRAINTS B
> WHERE A.TABLE_SCHEMA = B.TABLE_SCHEMA AND A.TABLE_NAME = B.TABLE_NAME
>   AND A.CONSTRAINT_NAME = B.CONSTRAINT_NAME AND B.CONSTRAINT_TYPE IS NOT NULL
> AND A.REFERENCED_TABLE_NAME = 'parent' AND A.TABLE_NAME = 'child' ORDER BY A.TABLE_SCHEMA, A.TABLE_NAME, A.ORDINAL_POSITION
>
>Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=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=on,cset_narrowing=on,sargable_casefold=on
>
>Writing a core file...
>Working directory at /<<PKGBUILDDIR>>/t/testdb
>Resource Limits (excludes unlimited resources):
>Limit                     Soft Limit           Hard Limit           Units
>Max stack size            8388608              unlimited            bytes
>Max core file size        0                    unlimited            bytes
>Max processes             30885                30885                processes
>Max open files            32184                32184                files
>Max locked memory         8388608              8388608              bytes
>Max pending signals       30885                30885                signals
>Max msgqueue size         819200               819200               bytes
>Max nice priority         0                    0
>Max realtime priority     0                    0
>Core pattern: core
>
>Kernel version: Linux version 6.12.73+deb13-cloud-amd64 (debian-kernel at lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Debian 6.12.73-1 (2026-02-17)
>
>DBD::mysql::db foreign_key_info failed: Lost connection to server during query at t/40catalog.t line 68.
>DBD::mysql::db foreign_key_info failed: Lost connection to server during query at t/40catalog.t line 68.
># Looks like your test exited with 11 just after 4.
>t/40catalog.t ...........................
>1..78
>ok 1 - connecting
>ok 2 - cleaning up
>ok 3
>ok 4
>Dubious, test returned 11 (wstat 2816, 0xb00)
>Failed 74/78 subtests

This looks like a problem in mariadb 1:11.8.6-1 (in unstable) to me, 
compared to 1:11.8.5-4 in testing (where libdbd-mysql-perl still 
builds successfully).

Looking through the mariadb bugs, I found #1127431, with an error log 
at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1127431;filename=mysql.err;msg=10 
and forwarded to https://jira.mariadb.org/browse/MDEV-38811 which 
looks kind of similar to me (the 
"information_schema.table_constraints" part). Maybe it's even to same 
bug …

Cc'in the mariadb maintainers.

Cheers,
gregor

-- 
  .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
    `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: Digital Signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-mysql-maint/attachments/20260218/e521e117/attachment.sig>