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

rpl_parallel_conflicts fails in buildbot

Details

    Description

      rpl.rpl_parallel_conflicts fails in buildbot:
      https://buildbot.mariadb.org/#/builders/572/builds/15452/steps/7/logs/stdio
      builder: apexis-bbw3-docker-msan-clang-debian-11

      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(__interceptor_backtrace+0x9f)[0x55724f84dd9f]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(my_print_stacktrace+0xae)[0x55725280d0ee]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(handle_fatal_signal+0x716)[0x557250924966]
      		 
      msan_interceptors.cpp.o:0(SignalHandler(int))[0x55724f87a63b]
      		 
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x13140)[0x7fc3f771f140]
      		 
      addr2line: DWARF error: invalid or unhandled FORM value: 0x25
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(_db_flush_+0x9b)[0x5572528a313b]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(_db_my_assert+0x94)[0x55724f6fb07a]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x322376a)[0x5572521e476a]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x31b810a)[0x55725217910a]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x2f45238)[0x557251f06238]
      		 
      row0purge.cc:0(row_purge_reposition_pcur(btr_latch_mode, purge_node_t*, mtr_t*))[0x557251ec65f9]
      		 
      row0purge.cc:0(row_purge_reset_trx_id(purge_node_t*, mtr_t*))[0x557251ed7144]
      		 
      row0purge.cc:0(row_purge(purge_node_t*, unsigned char const*, que_thr_t*))[0x557251ec9806]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x2f05e72)[0x557251ec6e72]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x2d3bed3)[0x557251cfced3]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x3034048)[0x557251ff5048]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x804c71)[0x55724f7c5c71]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x3037539)[0x557251ff8539]
      		 
      srv0srv.cc:0(purge_coordinator_callback(void*))[0x557251ff195d]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(_ZN5tpool10task_group7executeEPNS_4taskE+0x26d)[0x5572525db12d]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(_ZN5tpool19thread_pool_generic11worker_mainEPNS_11worker_dataE+0x20f)[0x5572525cdedf]
      		 
      /home/buildbot/amd64-debian-11-msan/build/sql/mariadbd(+0x36154c7)[0x5572525d64c7]
      		 
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x7ea7)[0x7fc3f7713ea7]
      		 
      /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fc3f711dacf]

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-23371 main.range_innodb failed in buildbot, server crashed in _db_doprnt_

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            I don’t understand why this is assigned to me. I see a SIGSEGV in the log, but due to the nearly useless built-in stack trace (see also MDEV-21010) I can’t tell if the SIGSEGV was triggered in some DBUG code that is not an integral part of InnoDB. This test is not failing much; I could not find a valid stack trace anywhere. Possibly, we should remove some DBUG instrumentation; I do not remember --debug-dbug=d,purge ever being useful.

            marko Marko Mäkelä added a comment - I don’t understand why this is assigned to me. I see a SIGSEGV in the log, but due to the nearly useless built-in stack trace (see also MDEV-21010 ) I can’t tell if the SIGSEGV was triggered in some DBUG code that is not an integral part of InnoDB. This test is not failing much; I could not find a valid stack trace anywhere. Possibly, we should remove some DBUG instrumentation; I do not remember --debug-dbug=d,purge ever being useful.
            marko Marko Mäkelä added a comment -

            A bug of the DBUG subsystem was worked around by removing some code elsewhere. This could be another occurrence of the same bug.

            Ever since the InnoDB stress testing started to make use of https://www.rr-project.org for about ⅓ of the runs, I do not see much value of having DBUG_PRINT instrumentation in InnoDB.

            marko Marko Mäkelä added a comment - A bug of the DBUG subsystem was worked around by removing some code elsewhere . This could be another occurrence of the same bug. Ever since the InnoDB stress testing started to make use of https://www.rr-project.org for about ⅓ of the runs, I do not see much value of having DBUG_PRINT instrumentation in InnoDB.
            marko Marko Mäkelä added a comment -

            I investigated this a little further. The original failure log is unavailable, and some cross-reference history may have been lost as well. There is some DBUG_EXECUTE_IF() in the code that row_purge_reposition_pcur() is invoking, but as far as I can tell, no DBUG_PRINT or DBUG_LOG that could be removed.

            I can see some DBUG_PRINT or DBUG_LOG in btr_cur_optimistic_insert(), btr_cur_update_in_place(), btr_cur_optimistic_update(), btr_cur_del_mark_set_clust_rec(), but none of that code is not being invoked by row_purge_reposition_pcur().

            I assume that when WITH_DBUG_TRACE is enabled, some of the DBUG_EXECUTE_IF macros could include additional logging that would cause trouble. I disabled some such logic in MDEV-29613 when improving cmake -DWITH_DBUG_TRACE=OFF.

            Given that this bug does not seem to occur anymore and given that a recent build log of amd64-debian-11-msan that I checked includes cmake -DWITH_DBUG_TRACE=OFF, it seems that this bug has been resolved already by modifying the Buildbot configuration.

            marko Marko Mäkelä added a comment - I investigated this a little further. The original failure log is unavailable, and some cross-reference history may have been lost as well. There is some DBUG_EXECUTE_IF() in the code that row_purge_reposition_pcur() is invoking, but as far as I can tell, no DBUG_PRINT or DBUG_LOG that could be removed. I can see some DBUG_PRINT or DBUG_LOG in btr_cur_optimistic_insert() , btr_cur_update_in_place() , btr_cur_optimistic_update() , btr_cur_del_mark_set_clust_rec() , but none of that code is not being invoked by row_purge_reposition_pcur() . I assume that when WITH_DBUG_TRACE is enabled, some of the DBUG_EXECUTE_IF macros could include additional logging that would cause trouble. I disabled some such logic in MDEV-29613 when improving cmake -DWITH_DBUG_TRACE=OFF . Given that this bug does not seem to occur anymore and given that a recent build log of amd64-debian-11-msan that I checked includes cmake -DWITH_DBUG_TRACE=OFF , it seems that this bug has been resolved already by modifying the Buildbot configuration.

            People

              marko Marko Mäkelä
              monty Michael Widenius
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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