Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-36652

Tests main.ctype_binary and main.ctype_latin1 crash on sparc64

Details

    • Bug
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • None
    • None
    • Tests
    • None

    Description

      Downstream issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053485

      Example log: https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=sparc64&ver=1%3A11.4.5-2%7Eexp1&stamp=1740288400&raw=0

      main.ctype_binary                        w7 [ fail ]
              Test ended at 2025-02-23 05:22:54
       
      CURRENT_TEST: main.ctype_binary
      mysqltest: At line 206: query 'SELECT COUNT(*) FROM t WHERE EXTRACTVALUE(c,'a')='a'' failed: <Unknown> (2013): Lost connection to server during query
       
      The result from queries just before the failure was:
      < snip >
      RETURN NULL	latin1	latin1_swedish_ci	latin1_swedish_ci
      DROP FUNCTION f1;
      CREATE FUNCTION f1(a ENUM('a') CHARACTER SET binary) RETURNS INT RETURN NULL;
      SHOW CREATE FUNCTION f1;
      Function	sql_mode	Create Function	character_set_client	collation_connection	Database Collation
      f1	STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION	CREATE DEFINER=`root`@`localhost` FUNCTION `f1`(a ENUM('a') CHARACTER SET binary) RETURNS int(11)
      RETURN NULL	latin1	latin1_swedish_ci	latin1_swedish_ci
      DROP FUNCTION f1;
      #
      # End of 10.3 tests
      #
      #
      # Start of 10.4 tests
      #
      #
      # MDEV-28384 UBSAN: null pointer passed as argument 1, which is declared to never be null in my_strnncoll_binary on SELECT ... COUNT or GROUP_CONCAT
      #
      CREATE TABLE t (c BLOB NOT NULL);
      INSERT IGNORE INTO t VALUES (0);
      SELECT COUNT(*) FROM t WHERE EXTRACTVALUE(c,'a')='a';
       
      More results from queries before failure can be found in /build/reproducible-path/mariadb-11.4.5/builddir/mysql-test/var/7/log/ctype_binary.log
       
       - found 'core' (1/1)
      Core generated by '/build/reproducible-path/mariadb-11.4.5/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 3510395]
      [New LWP 3510194]
      [New LWP 3510195]
      [New LWP 3510196]
      [New LWP 3510197]
      [New LWP 3510140]
      [New LWP 3510203]
      [New LWP 3510396]
      [New LWP 3510410]
       
      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.4.5/builddir/sql/mariadbd --defaults-group-suffix=.1 --defaults-file=/build/reproducible-path/mariadb-11.4.5/builddir/mysql-test/var/7/my.cnf --log-output=file --core-file --loose-debug-sync-timeout=300'.
      Program terminated with signal SIGUSR1, User defined signal 1.
      #0  0xffff800102b94e88 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
      [Current thread is 1 (Thread 0xffff8001111d68c0 (LWP 3510395))]
      #0  0xffff800102b94e88 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
      #1  0x0000010000ac44c4 in handle_fatal_signal (sig=10) at ./sql/signal_handler.cc:298
      #2  <signal handler called>
      #3  0x4d7953514c586964 in ?? ()
      Backtrace stopped: previous frame identical to this frame (corrupt stack?)
      

      Attachments

        Issue Links

          Activity

            According to man 7 signal on my Debian GNU/Linux system, signal 10 should be SIGBUS on SPARC. Unaligned access, maybe?

            marko Marko Mäkelä added a comment - According to man 7 signal on my Debian GNU/Linux system, signal 10 should be SIGBUS on SPARC. Unaligned access, maybe?

            It looks like the stack is corrupted and therefore a complete stack trace can’t be produced. Quoting from the build log:

            Thread 1 (Thread 0xffff800113dd48c0 (LWP 3498735)):
            #0  0xffff800102b94e88 in ?? () from /lib/sparc64-linux-gnu/libc.so.6
            No symbol table info available.
            #1  0x0000010000ac44c4 in handle_fatal_signal (sig=10) at ./sql/signal_handler.cc:298
                    curr_time = 1740287275
                    tm = {tm_sec = 55, tm_min = 7, tm_hour = 5, tm_mday = 23, tm_mon = 1, tm_year = 125, tm_wday = 0, tm_yday = 53, tm_isdst = 0, tm_gmtoff = 0, tm_zone = 0x10002496570 "UTC"}
                    thd = <optimized out>
            #2  <signal handler called>
            No symbol table info available.
            #3  0x4d7953514c586964 in ?? ()
            No symbol table info available.
            Backtrace stopped: previous frame identical to this frame (corrupt stack?)
            

            The stack traces of other threads look reasonable to me. I’m afraid that some additional debugging may be needed. Would enabling WITH_ASAN or WITH_UBSAN lead to a clearer failure? Unfortunately, we do not have any SPARC on https://buildbot.mariadb.org.

            marko Marko Mäkelä added a comment - It looks like the stack is corrupted and therefore a complete stack trace can’t be produced. Quoting from the build log: Thread 1 (Thread 0xffff800113dd48c0 (LWP 3498735)): #0 0xffff800102b94e88 in ?? () from /lib/sparc64-linux-gnu/libc.so.6 No symbol table info available. #1 0x0000010000ac44c4 in handle_fatal_signal (sig=10) at ./sql/signal_handler.cc:298 curr_time = 1740287275 tm = {tm_sec = 55, tm_min = 7, tm_hour = 5, tm_mday = 23, tm_mon = 1, tm_year = 125, tm_wday = 0, tm_yday = 53, tm_isdst = 0, tm_gmtoff = 0, tm_zone = 0x10002496570 "UTC"} thd = <optimized out> #2 <signal handler called> No symbol table info available. #3 0x4d7953514c586964 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) The stack traces of other threads look reasonable to me. I’m afraid that some additional debugging may be needed. Would enabling WITH_ASAN or WITH_UBSAN lead to a clearer failure? Unfortunately, we do not have any SPARC on https://buildbot.mariadb.org .

            People

              Unassigned Unassigned
              otto Otto Kekäläinen
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.