**REQUESTING HELP FROM SPARC64 PORTERS IN DEBIAN**

In a build of MariaDB 11.8.1 on official Debian builders for sparc64
multiple vector related tests crashed the server:

* main.mariadb-import
* main.vector
* main.vector_aria
* main.vector_funcs
* main.vector_innodb
* main.vector2_notembedded

These are all related to the new AI embeddings functionality in
MariaDB (https://mariadb.com/kb/en/vectors/), and is new code that has
never been tested on sparc64 before.

I reported this to upstream, who is willing to look into it, but have
no sparc64 access.

Thus I was hoping some of the Debian sparc64 porters could step in and
test a bit, and help upstream, as they seem responsive to fixing
sparc64.


Full log at https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=sparc64&ver=1%3A11.8.1-3&stamp=1745371074&raw=0

Example error:

main.mariadb-import                      w13 [ fail ]
        Test ended at 2025-04-23 01:10:56

CURRENT_TEST: main.mariadb-import
mysqltest: At line 112: query 'insert vec(v) values
(x'e360d63ebe554f3fcdbc523f4522193f5236083d'),
(x'f511303f72224a3fdd05fe3eb22a133ffae86a3f'),
(x'f09baa3ea172763f123def3e0c7fe53e288bf33e'),
(x'b97a523f2a193e3eb4f62e3f2d23583e9dd60d3f'),
(x'f7c5df3e984b2b3e65e59d3d7376db3eac63773e'),
(x'de01453ffa486d3f10aa4d3fdd66813c71cb163f'),
(x'76edfc3e4b57243f10f8423fb158713f020bda3e'),
(x'56926c3fdf098d3e2c8c5e3d1ad4953daa9d0b3e'),
(x'7b713f3e5258323f80d1113d673b2b3f66e3583f'),
(x'6ca1d43e9df91b3fe580da3e1c247d3f147cf33e')' failed: <Unknown>
(2013): Lost connection to server during query

main.vector2_notembedded                 w2 [ fail ]
        Test ended at 2025-04-23 01:13:42

CURRENT_TEST: main.vector2_notembedded
mysqltest: At line 36: query 'insert into t1 select 0x00000000 as v
from seq_1_to_1000' failed: <Unknown> (2013): Lost connection to
server during query

main.vector_innodb                       w2 [ fail ]
        Test ended at 2025-04-23 01:14:47

CURRENT_TEST: main.vector_innodb
mysqltest: At line 7: query 'insert t1 (v) values
(x'106d263fdf68ba3eb08d533f97d46e3fd1e1ec3edc4c123f984c563f621a233f'),
(x'd55bee3c56eb9e3e84e3093f838dce3eb7cd653fe32d7d3f12de133c5715d23e'),
(x'fcd5553f3822443f5dae413f2593493f7777363f5f7f113ebf12373d4d145a3f'),
(x'7493093fd9a27d3e9b13783f8c66653f0bd7d23e50db983d251b013f1dba133f'),
(x'2e30373fae331a3eba94153ee32bce3e3311b33d5bc75d3f6c25653eb769113f'),
(x'381d5f3f2781de3e4f011f3f9353483f9bb37e3edd622d3eabecb63ec246953e'),
(x'4ee5dc3e214b103f0e7e583f5f36473e79d7823ea872ec3e3ab2913d1b84433f'),
(x'8826243f7d20f03e5135593f83ba653e44572d3fa87e8e3e943e0e3f649a293f'),
(x'3859ac3e7d21823ed3f5753fc79c143e61d39c3cee39ba3eb0b0133e815c173f'),
(x'cff0d93c32941e3f64b22a3f1e4f083f4ea2563fbff4a63e12a4703f6c824b3f')'
failed: <Unknown> (2013): Lost connection to server during query

main.vector_aria                         w3 [ fail ]
        Test ended at 2025-04-23 01:16:00

CURRENT_TEST: main.vector_aria
mysqltest: At line 6: query 'alter table t add vector(f)' failed:
<Unknown> (2013): Lost connection to server during query

main.vector_funcs                        w3 [ fail ]
        Test ended at 2025-04-23 01:17:15

CURRENT_TEST: main.vector_funcs
mysqltest: At line 3: query 'insert t1 (v) values
(x'e360d63ebe554f3fcdbc523f4522193f5236083d'),
(x'f511303f72224a3fdd05fe3eb22a133ffae86a3f'),
(x'f09baa3ea172763f123def3e0c7fe53e288bf33e'),
(x'b97a523f2a193e3eb4f62e3f2d23583e9dd60d3f'),
(x'f7c5df3e984b2b3e65e59d3d7376db3eac63773e'),
(x'de01453ffa486d3f10aa4d3fdd66813c71cb163f'),
(x'76edfc3e4b57243f10f8423fb158713f020bda3e'),
(x'56926c3fdf098d3e2c8c5e3d1ad4953daa9d0b3e'),
(x'7b713f3e5258323f80d1113d673b2b3f66e3583f'),
(x'6ca1d43e9df91b3fe580da3e1c247d3f147cf33e')' failed: <Unknown>
(2013): Lost connection to server during query

The result from queries just before the failure was:
create table t1 (id int auto_increment primary key, v vector(5) not
null, vector index (v));
insert t1 (v) values (x'e360d63ebe554f3fcdbc523f4522193f5236083d'),
(x'f511303f72224a3fdd05fe3eb22a133ffae86a3f'),
(x'f09baa3ea172763f123def3e0c7fe53e288bf33e'),
(x'b97a523f2a193e3eb4f62e3f2d23583e9dd60d3f'),
(x'f7c5df3e984b2b3e65e59d3d7376db3eac63773e'),
(x'de01453ffa486d3f10aa4d3fdd66813c71cb163f'),
(x'76edfc3e4b57243f10f8423fb158713f020bda3e'),
(x'56926c3fdf098d3e2c8c5e3d1ad4953daa9d0b3e'),
(x'7b713f3e5258323f80d1113d673b2b3f66e3583f'),
(x'6ca1d43e9df91b3fe580da3e1c247d3f147cf33e');

 - found 'core.2910524' (1/1)
Core generated by
'/build/reproducible-path/mariadb-11.8.1/builddir/sql/mariadbd'
Output from gdb follows. The first stack trace is from the failing thread.
The following stack traces are from all threads (so the failing one is
duplicated).
--------------------------
[New LWP 2910561]
[New LWP 2910550]
[New LWP 2910552]
[New LWP 2910555]
[New LWP 2910524]
[New LWP 2910553]

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.debian.net>
Enable debuginfod for this session? (y or [n]) [answered N; input not
from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
Core was generated by
`/build/reproducible-path/mariadb-11.8.1/builddir/sql/mariadbd
--defaults-group-suffix=.1
--defaults-file=/build/reproducible-path/mariadb-11.8.1/builddir/mysql-test/var/3/my.cnf
--log-output=file --core-file --loose-debug-sync-timeout=300'.
Program terminated with signal SIGUSR1, User defined signal 1.
#0  0xfff8000102b951b0 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0xfff800010d9428e0 (LWP 2910561))]
#0  0xfff8000102b951b0 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
#1  0x0000010000aef804 in handle_fatal_signal (sig=10) at
./sql/signal_handler.cc:298
#2  <signal handler called>
#3  0x7265636f76657261 in ?? ()

Thread 6 (Thread 0xfff800010d8a68e0 (LWP 2910553)):
#0  0xfff8000102b9c6fc in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1  0xfff8000102b8f94c in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#2  0xfff8000102b8fcf8 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#3  0xfff8000102b928d8 in pthread_cond_wait () from
/lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00000100006f877c in psi_cond_wait (that=0x10001b0a250
<COND_manager>, mutex=0x10001b0a288 <LOCK_manager>, file=0x100011b1578
"./sql/sql_manager.cc", line=110) at ./mysys/my_thr_init.c:580
        state = {m_flags = 7, m_operation = (unknown: 0x8420e4),
m_cond = 0x100024df4c0, m_mutex = 0xfff80001001de4c0, m_thread =
0xfff80001035b5a40, m_timer_start = 1745371019612943831, m_timer =
0x100010b9254 <my_timer_nanoseconds>, m_wait = 0xfff80001035b6390}
        locker = 0xfff800010d8a5978
        result = <optimized out>
#5  0x00000100008420a8 in inline_mysql_cond_wait (that=<optimized
out>, mutex=<optimized out>, src_file=<optimized out>,
src_line=<optimized out>) at ./include/mysql/psi/mysql_thread.h:1070
No locals.
#6  handle_manager (arg=<optimized out>) at ./sql/sql_manager.cc:110
        cb = <optimized out>
        error = 0
        abstime = {tv_sec = 0, tv_nsec = 1}
        reset_flush_time = true
#7  0x0000010000d4eccc in pfs_spawn_thread (arg=<optimized out>) at
./storage/perfschema/pfs.cc:2198
        typed_arg = <optimized out>
        user_arg = 0x0
        user_start_routine = 0x10000841f58 <handle_manager(void*)>
        pfs = 0xfff80001035b5a40
        klass = <optimized out>
#8  0xfff8000102b93180 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0xfff8000100036420 (LWP 2910524)):
#0  0xfff8000102b9c6fc in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1  0xfff8000102b8f94c in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#2  0xfff8000102b8f9e8 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#3  0xfff8000102bfd430 in poll () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x0000010000733f34 in poll (__fds=<optimized out>,
__nfds=<optimized out>, __timeout=-1) at
/usr/include/sparc64-linux-gnu/bits/poll2.h:44
No locals.
#5  handle_connections_sockets () at ./sql/mysqld.cc:6467
        sock = {fd = 12, is_unix_domain_socket = <optimized out>,
is_extra_port = <optimized out>, address_family = <optimized out>,
m_psi = 0x10003331700}
        error_count = 0
        cAddr = {ss_family = 1, __ss_padding =
"\000\000\000\000\000\000\377\370\000\001\002\337\353x\377\370\000\001\002\340\f`\000\000\a\376\377\337>\221\000\000\001\000\000sb<\000\000\000\000\000\000Jt\000\000\001\000\001\031\335
\000\000\a\376\377\337>\221\000\000\001\000\000sUX\000\000\a\376\377\337>\221\000\000\001\000\000sN\024\000\000\000\a\000\000\000\000\377\370\000\001\000\035\207@\377\370\000\001\003[\026\300\0308\315\261\351U\237\311",
__ss_align = 1099529163348}
        retval = <optimized out>
        fds = {array = {buffer = 0x100033a2288 "", elements = 3,
max_element = 16, alloc_increment = 16, size_of_element = 8, m_psi_key
= 0, malloc_flags = 0}}
        termination_fds = {32, 33}
        event_fd = {fd = 32, events = 1, revents = 3168}
#6  0x0000010000735648 in run_main_loop () at ./sql/mysqld.cc:5749
No locals.
#7  mysqld_main (argc=<optimized out>, argv=<optimized out>) at
./sql/mysqld.cc:6172
        please_close_stdin = <optimized out>
        ho_error = <optimized out>
        new_thread_stack_size = <optimized out>
        user = <optimized out>
#8  0xfff8000102b2bf94 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#9  0xfff8000102b2c0b0 in __libc_start_main () from
/lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#10 0x0000010000726020 in _start ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0xfff800010d8f48e0 (LWP 2910555)):
#0  0xfff8000102b9c6fc in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1  0xfff8000102b8f94c in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#2  0xfff8000102b8f9e8 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#3  0xfff8000102b439ec in sigtimedwait () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x000001000072931c in my_sigwait (set=0xfff800010d8f3950,
sig=<synthetic pointer>, code=<synthetic pointer>) at
./include/my_pthread.h:180
        siginfo = {si_signo = 7, si_errno = 4, si_code = -524287,
__pad0 = 195585024, _sifields = {_pad = {0, 0, 256, 37879104, -524287,
56324288, 256, 53652882, 406375857, -398777575, 256, 17535572,
-524287, 56326672, 0, 0, -524287, 227488369, 256, 13954232, 0, 0, 0,
0, 0, 0, 0, 0}, _kill = {si_pid = 0, si_uid = 0}, _timer = {si_tid =
0, si_overrun = 0, si_sigval = {sival_int = 256, sival_ptr =
0x1000241fd40}}, _rt = {si_pid = 0, si_uid = 0, si_sigval = {sival_int
= 256, sival_ptr = 0x1000241fd40}}, _sigchld = {si_pid = 0, si_uid =
0, si_status = 256, si_utime = -2251795462393664, si_stime =
1099565280658}, _sigfault = {si_addr = 0x0, _si_trapno = 256,
si_addr_lsb = 577, _bounds = {_addr_bnd = {_lower =
0xfff80001035b70c0, _upper = 0x1000332ad92}, _pkey = 4294443009}},
_sigpoll = {si_band = 0, si_fd = 0}, _sigsys = {_call_addr = 0x0,
_syscall = 256, _arch = 37879104}}}
        siginfo = <optimized out>
#5  signal_hand () at ./sql/mysqld.cc:3277
        error = <optimized out>
        origin = <optimized out>
        set = {__val = {147461, 18444492278247161672, 0, 0,
18444492278418321841, 18444492278236601564, 0, 0, 0, 0, 2,
64749681383386723, 0, 0, 0, 0}}
        sig = <optimized out>
#6  0x0000010000d4eccc in pfs_spawn_thread (arg=<optimized out>) at
./storage/perfschema/pfs.cc:2198
        typed_arg = <optimized out>
        user_arg = 0x0
        user_start_routine = 0x100007291d0 <signal_hand(void*)>
        pfs = 0xfff80001035b70c0
        klass = <optimized out>
#7  0xfff8000102b93180 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0xfff800010d8598e0 (LWP 2910552)):
#0  0xfff8000102b9c6fc in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1  0xfff8000102b8f94c in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#2  0xfff8000102b8fcf8 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#3  0xfff8000102b92ab4 in pthread_cond_timedwait () from
/lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00000100006f87f4 in psi_cond_timedwait (that=0x1000233ef60
<COND_checkpoint>, mutex=0x1000233ef98 <LOCK_checkpoint>,
abstime=0xfff800010d858980, file=0x1000120cb10
"./storage/maria/ma_servicethread.c", line=115) at
./mysys/my_thr_init.c:593
        state = {m_flags = 7, m_operation = (unknown: 0x2e07340),
m_cond = 0x100024df240, m_mutex = 0xfff80001001ddb40, m_thread =
0xfff80001035b43c0, m_timer_start = 1745371019557554947, m_timer =
0x100010b9254 <my_timer_nanoseconds>, m_wait = 0xfff80001035b4d10}
        locker = 0xfff800010d858898
        result = <optimized out>
#5  0x0000010000ce1554 in inline_mysql_cond_timedwait
(src_file=0x1000120cb10 "./storage/maria/ma_servicethread.c",
src_line=115, that=<optimized out>, mutex=<optimized out>,
abstime=0xfff800010d858980) at ./include/mysql/psi/mysql_thread.h:1086
No locals.
#6  my_service_thread_sleep (control=0x10001a33108
<checkpoint_control>, sleep_time=<optimized out>) at
./storage/maria/ma_servicethread.c:115
        abstime = {tv_sec = 1745371048, tv_nsec = 557554000}
        res = 0 '\000'
#7  0x0000010000cd856c in ma_checkpoint_background (arg=0x1e) at
./storage/maria/ma_checkpoint.c:726
        interval = 30
        sleeps = 1
        sleep_time = 29
        log_horizon_at_last_checkpoint = 4295395181
        pagecache_flushes_at_last_checkpoint = 0
        pages_bunch_size = 0
        filter_param = {up_to_lsn = 4295395137, max_pages = 0}
        dfile = 0x0
        kfile = 0x0
#8  0x0000010000d4eccc in pfs_spawn_thread (arg=<optimized out>) at
./storage/perfschema/pfs.cc:2198
        typed_arg = <optimized out>
        user_arg = 0x1e
        user_start_routine = 0x10000cd843c <ma_checkpoint_background>
        pfs = 0xfff80001035b43c0
        klass = <optimized out>
#9  0xfff8000102b93180 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 0xfff8000100cdd8e0 (LWP 2910550)):
#0  0xfff8000102b9c6fc in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1  0xfff8000102b8f94c in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#2  0xfff8000102b8fcf8 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#3  0xfff8000102b92ab4 in pthread_cond_timedwait () from
/lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00000100006f87f4 in psi_cond_timedwait (that=0x100023cb5e8
<COND_timer>, mutex=0x100023cb620 <LOCK_timer>,
abstime=0xfff8000100cdca60, file=0x1000126a758 "./mysys/thr_timer.c",
line=329) at ./mysys/my_thr_init.c:593
        state = {m_flags = 7, m_operation = (unknown: 0x126a2c0),
m_cond = 0x100024deb40, m_mutex = 0xfff80001001d9d40, m_thread =
0xfff80001035b2d40, m_timer_start = 1745371019533702199, m_timer =
0x100010b9254 <my_timer_nanoseconds>, m_wait = 0xfff80001035b3690}
        locker = 0xfff8000100cdc968
        result = <optimized out>
#5  0x00000100010a52f0 in inline_mysql_cond_timedwait
(that=0x100023cb5e8 <COND_timer>, mutex=0x100023cb620 <LOCK_timer>,
src_file=0x1000126a758 "./mysys/thr_timer.c", src_line=329,
abstime=0xfff8000100cdca60) at ./include/mysql/psi/mysql_thread.h:1086
No locals.
#6  timer_handler (arg=<optimized out>) at ./mysys/thr_timer.c:329
        error = <optimized out>
        top_time = 0x100023cb580 <max_timer_data>
        now = <optimized out>
        abstime = {tv_sec = 4294967295, tv_nsec = 0}
#7  0x0000010000d4eccc in pfs_spawn_thread (arg=<optimized out>) at
./storage/perfschema/pfs.cc:2198
        typed_arg = <optimized out>
        user_arg = 0x0
        user_start_routine = 0x100010a50b0 <timer_handler>
        pfs = 0xfff80001035b2d40
        klass = <optimized out>
#8  0xfff8000102b93180 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0xfff800010d9428e0 (LWP 2910561)):
#0  0xfff8000102b951b0 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x0000010000aef804 in handle_fatal_signal (sig=10) at
./sql/signal_handler.cc:298
        curr_time = 1745371020
        tm = {tm_sec = 0, tm_min = 17, tm_hour = 1, tm_mday = 23,
tm_mon = 3, tm_year = 125, tm_wday = 3, tm_yday = 112, tm_isdst = 0,
tm_gmtoff = 0, tm_zone = 0x100024ac6f0 "UTC"}
        thd = <optimized out>
#2  <signal handler called>
No symbol table info available.
#3  0x7265636f76657261 in ?? ()
No symbol table info available.

Hi Otto,
there is a very fast sparc64 (SPARC M8 clocked at 5 GHz) machine available
running Solaris 11.4 in the GCC Compile Farm for which any open source
developer can request an account for, see:

- https://gcc.gnu.org/wiki/CompileFarm
- https://portal.cfarm.net/machines/list/

We also have a sparc64 machine there running Debian unstable, but it's
currently offline due to CPU problems. However, we have now finally
purchased replacement CPUs and we are confident to get the machine back
online soon.

If upstream is really willing to work on sparc64 and they want to get the
bug fixed as soon as possible, there would also be the possibility to create
a DSA guest account to gain access to stadler.debian.net which is a SPARC T4
running Debian unstable.

See: https://dsa.debian.org/doc/guest-account/

Since you're a DD, you can request a DSA guest account for them. They will
need to specify what architectures they need access to. Access to other
architectures is available as well, also through the GCC Compile Farm.

I highly recommend the MariaDB people to request a GCC Compile Farm account
if they haven't done so yet. I assume they would be interested to test their
software on the various architectures offered there as well. And maybe they
can also just use the Solaris 11.4 SPARC M8 to fix the sparc64 crashes.

Adrian

Thanks for the tips, I relayed suggestion about GCC Compile Farm to upstream.

Also I noticed that the sparc64 crashes are pretty random, happening
in different tests. Maybe the runner is unstable?

For example in https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=sparc64&ver=1%3A11.8.1-4&stamp=1745481491&raw=0
the failing tests were:

main.status main.vector2 main.query_cache
main.set_statement_notembedded main.ssl_timeout main.log_state
main.userstat main.backup_lock_binlog main.lock_multi main.xa

In https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=sparc64&ver=1%3A11.8.1-4&stamp=1745449363&raw=0
the failing tests were:

main.vector2 main.concurrent_innodb_safelog main.sp-innodb main.check

Hi Otto,

Did you try reproducing the issue on stadler.debian.net? If it's an issue
with the host machine, you should be able to run the tests successfully
on the porterbox.

Adrian

Hi!

Yes, I tried the build on the porterbox and it is crashing, and
repeated runs seem to crash on the same tests, but not exactly every
time.

Completed: Failed 14/1131 tests, 98.76% were successful.
Failing test(s): main.bind_address_resolution
main.bind_multiple_addresses_resolution
main.log_slow_always_query_time main.connect main.set_statement
main.unsafe_binlog_innodb

Completed: Failed 10/1130 tests, 99.12% were successful.
Failing test(s): main.bind_multiple_addresses_resolution
main.bind_address_resolution main.partition_innodb_semi_consistent
main.subselect_no_mat main.sp-i_s_columns

-----
Notes to self on how to build on stadler.debian.net:

ssh ssh stadler.debian.net
source porterbox.sh
pend # remove any old schroots
psetup # create a new schroot
pinstall git-buildpackage gdb debian-goodies libipc-system-simple-perl
# install prerequisites
pchroot # enter schroot
gbp clone --verbose vcs-git:mariadb # gbp not on host, must run from
inside schroot
exit
pdeps mariadb # install build dependencies
pchroot # enter again to start actual build
cd mariadb
gbp buildpackage --git-verbose --git-no-pristine-tar  -us -uc

# rerun test after build when artifacts are still around using
# commands copied from buildlog
cd builddir/mysql-test
./mtr --force --testcase-timeout=120 --suite-timeout=540 --retry=3 \
      --verbose-restart --max-save-core=1 --max-save-datadir=1 \
      --parallel=48 --skip-rpl --suite=main \
      --skip-test-list=/tmp/tmp.MTnxYcCghC

I think you're missing libc6-dbg (and possibly some other debugging symbols).

I'm also surprised by the SIGUSR1. Is this really a crash?

Maybe the USR1 signal is from the test runner that kills the process after
it has been stuck for a long time.

I observed the first tests run quickly but then it grinds to a halt. But it
could just be because of hitting the bug that traps stops/crashes server
without returning control.

I didn't install all symbols as I don't have the skills to read the full
code path / stack trace and write a patch for sparc64 compatibility myself.

I am not debugging this further right now, need to debug upgrade issues
that affects all platforms.

Looking at the most recent MariaDB builds on at
https://buildd.debian.org/status/package.php?p=mariadb seems x32 is
failing on these same vector functions.

In the sparc64 build they are skipped, but the post-build MTR test is
failing on other tests crashing:
...
main.delete_use_source_engines           w13 [ pass ]  32203
main.partition_innodb                    w3 [ pass ]  77352
main.update_use_source                   w21 [ pass ]  52894
main.update_innodb                       w30 [ pass ]  35943
main.parser_bug21114_innodb              w16 [ pass ]  133529
main.long_unique_innodb                  w17 [ retry-fail ]
        Test ended at 2025-11-08 21:44:11

CURRENT_TEST: main.long_unique_innodb
mysqltest: At line 165: query 'update ignore t1 set f = 'x'' failed
with wrong errno <Unknown> (2013): 'Lost connection to server during
query', instead of ER_NOT_SUPPORTED_YET (1235)...
...
Completed: Failed 6/1135 tests, 99.47% were successful.
Failing test(s): main.long_unique_innodb main.alter_table_lock
main.unsafe_binlog_innodb
...

This bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104002
has steps to reproduce how I tested sparc64 builds and MTR on
stadler.debian.net myself in case somebody has bandwidth to try to
make MariaDB run well on sparc64.

I ran a detailed stack trace on stadler.debian.net and posted it in
upstream Jira at https://jira.mariadb.org/browse/MDEV-36670 in hopes
upstream could gain valuable insights from reading it. I also posted
there my notes on the exact steps I ran on stadler to build MariaDB
and run mariadb-test-run in case someone wants to repeat it. I can
also post the same thing here if you think it is valuable for Debian
bug tracking.

I'm clueless about the initial stack trace with the SIGUSR1s, but the SIGILL one you posted further below seems very odd and somewhat unrelated, but still serious.

_sparcv9_random is from OpenSSL, and while I can't find the exact version, I think it matches this piece of code:
https://github.com/openssl/openssl/blob/0e9725bcb90770d967351b977407b174bbd91869/crypto/sparccpuid.S#L347-L353

Not sure if there's an issue with the hardcoded opcode, or perhaps an incorrectly identified CPU type, but the .size line seems off. Shouldn't this read ".size _sparcv9_random,.-_sparcv9_random" instead?