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

Test main.mysql_client_test_nonblock fails on arm64 (aarch64)

Details

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

    Description

      While testing MariaDB 11.4.5 on Ubuntu I ran into this:

      main.mysql_client_test_nonblock          w5 [ fail ]
      		 
              Test ended at 2025-02-17 18:59:09
      		 
       
      		 
      CURRENT_TEST: main.mysql_client_test_nonblock
      		 
      mysqltest: At line 23: exec of '/<<PKGBUILDDIR>>/builddir/tests/mariadb-client-test --defaults-file=/<<PKGBUILDDIR>>/builddir/mysql-test/var/5/my.cnf --testcase --vardir=/<<PKGBUILDDIR>>/builddir/mysql-test/var/5 --non-blocking-api --getopt-ll-test=25600M >> /<<PKGBUILDDIR>>/builddir/mysql-test/var/5/log/mysql_client_test.out.log 2>&1' failed, error: 35584, status: 139, errno: 11
      		 
      Output from before failure:
      		 
      call mtr.add_suppression(" IP address .* could not be resolved");
      		 
       
      		 
      The result from queries just before the failure was:
      		 
      SET @old_general_log= @@global.general_log;
      		 
      SET @old_slow_query_log= @@global.slow_query_log;
      		 
      call mtr.add_suppression(" Error reading file './client_test_db/test_frm_bug.frm'");
      		 
      call mtr.add_suppression(" IP address .* could not be resolved");

      Full log at https://launchpadlibrarian.net/777266409/buildlog_ubuntu-plucky-arm64.mariadb_1%3A11.4.5-1~bpo25.04.1~1739813055.603ca9b90ea+feature.extend.mtr.to.big_BUILDING.txt.gz

      It may be related to MDEV-15096 but test fails in a different way.

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          otto Otto Kekäläinen created issue -
          marko Marko Mäkelä added a comment -

          Status 139 should be 128+11 = 128 + SIGSEGV, which is often caused by dereferencing a null pointer. I didn’t find a recent failure in our CI that would be exactly like that. The failures on our CI are for CMAKE_BUILD_TYPE=Debug, which could mean that they’re failing a little earlier during the execution. According to man 7 signal, the default action for handling SIGSEGV should be to produce a core dump. Could we get one from that environment?

          marko Marko Mäkelä added a comment - Status 139 should be 128+11 = 128 + SIGSEGV, which is often caused by dereferencing a null pointer. I didn’t find a recent failure in our CI that would be exactly like that. The failures on our CI are for CMAKE_BUILD_TYPE=Debug , which could mean that they’re failing a little earlier during the execution. According to man 7 signal , the default action for handling SIGSEGV should be to produce a core dump. Could we get one from that environment?
          elenst Elena Stepanova made changes -
          Field Original Value New Value
          Comment [ It looks the same as failures in the *comments* to MDEV-15096.
          Oddly, according to the cross-reference, the test hadn't failed in buildbots for almost a year, but started failing again just a few days ago. ]
          elenst Elena Stepanova made changes -
          Status Open [ 1 ] Needs Feedback [ 10501 ]
          serg Sergei Golubchik made changes -
          Status Needs Feedback [ 10501 ] Open [ 1 ]

          People

            Unassigned Unassigned
            otto Otto Kekäläinen
            Votes:
            0 Vote for this issue
            Watchers:
            4 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.