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

v11.4.5 build on Fedora41/gcc14 FAILs; v11.4.4 OK (error: `mutex_owner` was not declared in this scope)

Details

    • Bug
    • Status: Confirmed (View Workflow)
    • Blocker
    • Resolution: Unresolved
    • 11.4.5
    • 10.6, 10.11, 11.4
    • Compiling
    • Fedora41 + gcc (GCC) 14.2.1 20250110 (Red Hat 14.2.1-7)

    Description

      BUILD: mariadb-lts git_mariadb_11.4.4
      on Fedora41 + gcc (GCC) 14.2.1 20250110 (Red Hat 14.2.1-7)
      OK
      -> log: https://pastebin.com/aHQzV8Qk

      BUILD: mariadb-lts git_mariadb_11.4.5
      on Fedora41 + gcc (GCC) 14.2.1 20250110 (Red Hat 14.2.1-7)
      FAILS
      -> https://pastebin.com/5FRnJnfy, line # 907

      ```

      ...
      /builddir/build/BUILD/mariadb-lts-git_mariadb_11.4.5-build/server.git-e2c746b03313677dd880ed7f5ada49c17c8c1b1c/storage/innobase/include/trx0trx.h: In member function ‘void trx_t::mutex_lock()’:
      /builddir/build/BUILD/mariadb-lts-git_mariadb_11.4.5-build/server.git-e2c746b03313677dd880ed7f5ada49c17c8c1b1c/storage/innobase/include/trx0trx.h:674:13: error: ‘mutex_owner’ was not declared in this scope
      674 | assert(!mutex_owner.exchange(pthread_self(),

      ^~~~~~~~~~~
      /builddir/build/BUILD/mariadb-lts-git_mariadb_11.4.5-build/server.git-e2c746b03313677dd880ed7f5ada49c17c8c1b1c/storage/innobase/include/trx0trx.h: In member function ‘void trx_t::mutex_unlock()’:
      /builddir/build/BUILD/mariadb-lts-git_mariadb_11.4.5-build/server.git-e2c746b03313677dd880ed7f5ada49c17c8c1b1c/storage/innobase/include/trx0trx.h:680:12: error: ‘mutex_owner’ was not declared in this scope
      680
      assert(mutex_owner.exchange(0, std::memory_order_relaxed) ==
      ^~~~~~~~~~~
      ...
      ```

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment -

            regression from 43233fe469fd85d7c64978f01ed68de3288d43cc

            mutex_owner is behind UNIV_DEBUG

            diff --git a/storage/innobase/include/trx0trx.h b/storage/innobase/include/trx0trx.h
            index 889437aa1d2..ef11f5edd1c 100644
            --- a/storage/innobase/include/trx0trx.h
            +++ b/storage/innobase/include/trx0trx.h
            @@ -658,10 +658,8 @@ struct trx_t : ilist_node<>
               /** mutex protecting state and some of lock
               (some are protected by lock_sys.latch) */
               srw_spin_mutex mutex;
            -#ifdef UNIV_DEBUG
               /** The owner of mutex (0 if none); protected by mutex */
               std::atomic<pthread_t> mutex_owner{0};
            -#endif /* UNIV_DEBUG */
             public:
               void mutex_init() { mutex.init(); }
               void mutex_destroy() { mutex.destroy(); }
            

            danblack Daniel Black added a comment - regression from 43233fe469fd85d7c64978f01ed68de3288d43cc mutex_owner is behind UNIV_DEBUG diff --git a/storage/innobase/include/trx0trx.h b/storage/innobase/include/trx0trx.h index 889437aa1d2..ef11f5edd1c 100644 --- a/storage/innobase/include/trx0trx.h +++ b/storage/innobase/include/trx0trx.h @@ -658,10 +658,8 @@ struct trx_t : ilist_node<> /** mutex protecting state and some of lock (some are protected by lock_sys.latch) */ srw_spin_mutex mutex; -#ifdef UNIV_DEBUG /** The owner of mutex (0 if none); protected by mutex */ std::atomic<pthread_t> mutex_owner{0}; -#endif /* UNIV_DEBUG */ public: void mutex_init() { mutex.init(); } void mutex_destroy() { mutex.destroy(); }
            pgnd pgnd added a comment -

            pastebin has decided the log's "harmful" and deleted it ...

            reposting ->

            BUILD: mariadb-lts git_mariadb_11.4.4

            -> https://gist.github.com/pgnd/7973b0eb1f0d787c55a4c020c0fb00a6

            pgnd pgnd added a comment - pastebin has decided the log's "harmful" and deleted it ... reposting -> BUILD: mariadb-lts git_mariadb_11.4.4 -> https://gist.github.com/pgnd/7973b0eb1f0d787c55a4c020c0fb00a6

            A combination of

            -DCMAKE_BUILD_TYPE=None '-DCMAKE_C_FLAGS=-DDBUG_OFF' '-DCMAKE_CXX_FLAGS=-DDBUG_OFF'
            

            is what makes it different from our CI builds, both release and debug, and apparently with the change above it becomes too confusing for the build to get through.

            -DCMAKE_BUILD_TYPE=RelWithDebInfo is fine; the absence of DCMAKE_BUILD_TYPE defaults to RelWithDebInfo; and -DCMAKE_BUILD_TYPE=Debug with simultaneous DBUG_OFF would fail regardless the recent change.

            I think it's not the first time when -DCMAKE_BUILD_TYPE=None causes a trouble, maybe something should be done about it.

            elenst Elena Stepanova added a comment - A combination of -DCMAKE_BUILD_TYPE=None '-DCMAKE_C_FLAGS=-DDBUG_OFF' '-DCMAKE_CXX_FLAGS=-DDBUG_OFF' is what makes it different from our CI builds, both release and debug, and apparently with the change above it becomes too confusing for the build to get through. -DCMAKE_BUILD_TYPE=RelWithDebInfo is fine; the absence of DCMAKE_BUILD_TYPE defaults to RelWithDebInfo; and -DCMAKE_BUILD_TYPE=Debug with simultaneous DBUG_OFF would fail regardless the recent change. I think it's not the first time when -DCMAKE_BUILD_TYPE=None causes a trouble, maybe something should be done about it.
            pgnd pgnd added a comment - - edited

            it's been quite awhile, so my specifics are fuzzy ...

            iirc, i'd
            ```

            • CMAKE_BUILD_TYPE="Release"
              + CMAKE_BUILD_TYPE="None"
              ```

            as =Release was pulling in default flags that were causing me some grief with my local builds.
            =None gave me a preferable blank-slate to work with.

            pgnd pgnd added a comment - - edited it's been quite awhile, so my specifics are fuzzy ... iirc, i'd ``` CMAKE_BUILD_TYPE="Release" + CMAKE_BUILD_TYPE="None" ``` as =Release was pulling in default flags that were causing me some grief with my local builds. =None gave me a preferable blank-slate to work with.
            pgnd pgnd added a comment -

            fwiw, a build of mdb git 11.6 branch is also good, here.

            pgnd pgnd added a comment - fwiw, a build of mdb git 11.6 branch is also good, here.

            There is some more discussion on this in MDEV-36113.

            marko Marko Mäkelä added a comment - There is some more discussion on this in MDEV-36113 .

            pgnd None of the pastes work any more.

            Can you please paste your cmake line? If you're still having trouble, it's likely because you are overwriting CMAKE_C_FLAGS and CMAKE_CXX_FLAGS instead of appending to them.

            cvicentiu Vicențiu Ciorbaru added a comment - pgnd None of the pastes work any more. Can you please paste your cmake line? If you're still having trouble, it's likely because you are overwriting CMAKE_C_FLAGS and CMAKE_CXX_FLAGS instead of appending to them.
            arkamar Petr Vaněk added a comment -

            Similar/same issue was reported in gentoo with the full log, see https://bugs.gentoo.org/949720.

            arkamar Petr Vaněk added a comment - Similar/same issue was reported in gentoo with the full log, see https://bugs.gentoo.org/949720 .
            pgnd pgnd added a comment -

            > your cmake line

            the attachment, `cmake.txt`

            WORKS for 11.4.4/release build
            FAILS for 11.4.5/release build
            WORKS for 11.6/branch build

            pgnd pgnd added a comment - > your cmake line the attachment, `cmake.txt` WORKS for 11.4.4/release build FAILS for 11.4.5/release build WORKS for 11.6/branch build
            arkamar Petr Vaněk added a comment -

            I have bisected the issue between 11.4.4 and 11.4.5 to the commit 43233fe469fd ("Fix -DBUILD_CONFIG=mysql_release to keep standard cmake flags").

            arkamar Petr Vaněk added a comment - I have bisected the issue between 11.4.4 and 11.4.5 to the commit 43233fe469fd ("Fix -DBUILD_CONFIG=mysql_release to keep standard cmake flags").
            pgnd pgnd added a comment -

            same as mentioned above, correct?

            > Daniel Black added a comment - 2025-02-06 23:56
            > regression from 43233fe469fd85d7c64978f01ed68de3288d43cc

            pgnd pgnd added a comment - same as mentioned above, correct? > Daniel Black added a comment - 2025-02-06 23:56 > regression from 43233fe469fd85d7c64978f01ed68de3288d43cc
            arkamar Petr Vaněk added a comment -

            ah, yes, the same one.

            arkamar Petr Vaněk added a comment - ah, yes, the same one.

            People

              cvicentiu Vicențiu Ciorbaru
              pgnd pgnd
              Votes:
              0 Vote for this issue
              Watchers:
              7 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.