Details

    Description

      From the compilation log:

      build/mariadb/src/mariadb-5.5.34/storage/tokudb/ft-index/ft/ft-ops.cc: In function 'ft_leaf_run_gc':
      /build/mariadb/src/mariadb-5.5.34/storage/tokudb/ft-index/ft/ft-ops.cc:2261:26: error: 'leaf_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized]
           if (leaf_entry->type != LE_MVCC) {
                                ^
       
      /build/mariadb/src/mariadb-5.5.34/storage/tokudb/ft-index/ft/ft-ops.cc: In function 'ft_leaf_run_gc':
      /build/mariadb/src/mariadb-5.5.34/storage/tokudb/ft-index/ft/ft-ops.cc:2261:26: error: 'leaf_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized]
           if (leaf_entry->type != LE_MVCC) {
                                ^

      As a temporary workaround I decided to disable TokuDB engine, but I want to re-enable it as soon as it possible.

      Attachments

        Issue Links

          Activity

            grknight Brian Evans added a comment -

            -Werror should be moved to debug targets or removed from /storage/tokudb/ft-index/cmake_modules/TokuSetupCompiler.cmake
            It is a great debug tool, but should not be in a release.

            grknight Brian Evans added a comment - -Werror should be moved to debug targets or removed from /storage/tokudb/ft-index/cmake_modules/TokuSetupCompiler.cmake It is a great debug tool, but should not be in a release.
            leif Leif Walsh added a comment -

            This is tracked upstream here: https://github.com/Tokutek/ft-index/issues/109

            I cannot reproduce this issue. Can you attach the CMakeCache.txt from when you found this problem?

            leif Leif Walsh added a comment - This is tracked upstream here: https://github.com/Tokutek/ft-index/issues/109 I cannot reproduce this issue. Can you attach the CMakeCache.txt from when you found this problem?

            Of course. I've pasted it here[1] and added as an attachment to the bug report.

            [1] http://sprunge.us/FVPj

            barthalion Bartłomiej Piotrowski (Inactive) added a comment - - edited Of course. I've pasted it here [1] and added as an attachment to the bug report. [1] http://sprunge.us/FVPj
            leif Leif Walsh added a comment -

            Ok, I can reproduce if I run cmake with no options. Can you try configuring with "cmake -DBUILD_CONFIG=mysql_release"? That should work fine. I think this just has to do with our handling of the Release vs. RelWithDebInfo configurations, I'll update the upstream ticket.

            leif Leif Walsh added a comment - Ok, I can reproduce if I run cmake with no options. Can you try configuring with "cmake -DBUILD_CONFIG=mysql_release"? That should work fine. I think this just has to do with our handling of the Release vs. RelWithDebInfo configurations, I'll update the upstream ticket.

            Yes, apparently -DBUILD_CONFIG=Release is the culprit. Everything builds fine with mysql_release. Thank you.

            barthalion Bartłomiej Piotrowski (Inactive) added a comment - Yes, apparently -DBUILD_CONFIG=Release is the culprit. Everything builds fine with mysql_release. Thank you.

            In my opinion the problem should not be hidden with some compiler adjustments, instead why not try to fix the actual cause ? E.g. following will silence the compiler very effectively:

            === modified file 'storage/tokudb/ft-index/ft/ft-ops.cc'
            --- storage/tokudb/ft-index/ft/ft-ops.cc	2013-10-04 20:49:53 +0000
            +++ storage/tokudb/ft-index/ft/ft-ops.cc	2014-02-04 18:04:06 +0000
            @@ -2330,7 +2330,7 @@
                 while (index < (num_leafentries_before = bn->data_buffer.omt_size())) {
                     void* keyp = NULL;
                     uint32_t keylen = 0;
            -        LEAFENTRY leaf_entry;
            +        LEAFENTRY leaf_entry = 0;
                     bn->data_buffer.fetch_klpair(index, &leaf_entry, &keylen, &keyp);
                     assert_zero(r);
                     ft_basement_node_gc_once(

            jplindst Jan Lindström (Inactive) added a comment - In my opinion the problem should not be hidden with some compiler adjustments, instead why not try to fix the actual cause ? E.g. following will silence the compiler very effectively: === modified file 'storage/tokudb/ft-index/ft/ft-ops.cc' --- storage/tokudb/ft-index/ft/ft-ops.cc 2013-10-04 20:49:53 +0000 +++ storage/tokudb/ft-index/ft/ft-ops.cc 2014-02-04 18:04:06 +0000 @@ -2330,7 +2330,7 @@ while (index < (num_leafentries_before = bn->data_buffer.omt_size())) { void* keyp = NULL; uint32_t keylen = 0; - LEAFENTRY leaf_entry; + LEAFENTRY leaf_entry = 0; bn->data_buffer.fetch_klpair(index, &leaf_entry, &keylen, &keyp); assert_zero(r); ft_basement_node_gc_once(
            leif Leif Walsh added a comment -

            That doesn't fix anything, that just hides the problem a different way. If execution were to reach the warned line with your change, it would segfault. The right thing to do is to keep it uninitialized at declaration, and to demonstrate (with asserts) to the compiler that execution cannot reach that line without initializing that variable. This was due to a typo and has already been fixed upstream.

            Sent from my iPhone

            leif Leif Walsh added a comment - That doesn't fix anything, that just hides the problem a different way. If execution were to reach the warned line with your change, it would segfault. The right thing to do is to keep it uninitialized at declaration, and to demonstrate (with asserts) to the compiler that execution cannot reach that line without initializing that variable. This was due to a typo and has already been fixed upstream. Sent from my iPhone

            The upstream (TokuDB) bug was closed as fixed quite some time ago, in March. So, I'm closing this one as fixed too. 'Fix Version' values are bogus, the fix should have made to the trees long before 10.0.14 and 5.5.40.

            Please comment if it didn't happen and the bug still exists.

            elenst Elena Stepanova added a comment - The upstream (TokuDB) bug was closed as fixed quite some time ago, in March. So, I'm closing this one as fixed too. 'Fix Version' values are bogus, the fix should have made to the trees long before 10.0.14 and 5.5.40. Please comment if it didn't happen and the bug still exists.

            People

              Unassigned Unassigned
              barthalion Bartłomiej Piotrowski (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              7 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.