[MDEV-5347] TokuDB compilation errors @ 5.5.34 Created: 2013-11-26  Updated: 2014-11-16  Resolved: 2014-11-16

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - TokuDB
Affects Version/s: 5.5.34, 10.0.7
Fix Version/s: 5.5.40, 10.0.14

Type: Bug Priority: Minor
Reporter: Bartłomiej Piotrowski (Inactive) Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: tokudb, upstream-fixed
Environment:

Arch Linux, gcc 4.8.2


Attachments: Text File CMakeCache.txt    
Issue Links:
Duplicate
duplicates MDEV-5465 Build failure in tokudb/ft-index on o... Closed
duplicates MDEV-5546 TokuDB compilation failure (ft-ops.cc) Closed
duplicates MDEV-5610 tokudb does not compile Closed

 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.



 Comments   
Comment by Brian Evans [ 2013-11-27 ]

-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.

Comment by Leif Walsh [ 2013-12-02 ]

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?

Comment by Bartłomiej Piotrowski (Inactive) [ 2013-12-02 ]

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

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

Comment by Leif Walsh [ 2013-12-02 ]

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.

Comment by Bartłomiej Piotrowski (Inactive) [ 2013-12-03 ]

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

Comment by Jan Lindström (Inactive) [ 2014-02-05 ]

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(

Comment by Leif Walsh [ 2014-02-05 ]

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

Comment by Elena Stepanova [ 2014-11-16 ]

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.

Generated at Thu Feb 08 07:03:35 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.